That is, we successfully initialize the new Terra, print inside it, and return. The return value seems to be corrupt and no Lua APIs I've tried have been able to get anything from it at all (e.g., lua_type, luaL_typename).
To be sure, I checked the luaL_checknumber declaration and it matches the reference manual. I also checked the value of lua_Number in luaconf.h in the specific installation and it matched double. (But it would be frankly strange for any of this to be off since it matches on every other platform we've run on.)
Running the test with this line commented out allows it to run to completion, but obviously fails because the correct result is not returned.
I also noticed the presence of heisenbugs when introducing printf calls, suggesting the possibility of bad calling convention support reading the wrong memory locations (or similar).
For simplicity, I modified the test to run a "sequential" version where I enable the Windows workaround to stub out the pthreads API. Therefore there are no threads in the test and no possibility of concurrency bugs.
Right now I'm inclined to chalk this up to Moonjit misbehaving again, though my evidence is circumstantial.
On PPC64le, multiterra.t crashes with a segfault. Debugging points to this line:
https://github.com/terralang/terra/blob/c33c4ba11460a3026c772f2841607827d692694e/tests/multiterra.t#L50
That is, we successfully initialize the new Terra, print inside it, and return. The return value seems to be corrupt and no Lua APIs I've tried have been able to get anything from it at all (e.g.,
lua_type,luaL_typename).To be sure, I checked the
luaL_checknumberdeclaration and it matches the reference manual. I also checked the value oflua_Numberinluaconf.hin the specific installation and it matcheddouble. (But it would be frankly strange for any of this to be off since it matches on every other platform we've run on.)Running the test with this line commented out allows it to run to completion, but obviously fails because the correct result is not returned.
I also noticed the presence of heisenbugs when introducing
printfcalls, suggesting the possibility of bad calling convention support reading the wrong memory locations (or similar).For simplicity, I modified the test to run a "sequential" version where I enable the Windows workaround to stub out the pthreads API. Therefore there are no threads in the test and no possibility of concurrency bugs.
Right now I'm inclined to chalk this up to Moonjit misbehaving again, though my evidence is circumstantial.