Re: Calculation/Numeric corruption of Data in LuaJIT 2.1RC3
- From: Mike Pall <mikelj-1705@xxxxxxx>
- To: luajit@xxxxxxxxxxxxx
- Date: Fri, 19 May 2017 20:08:02 +0200
Caswal Parker wrote:
If I wrap the offending while loop inside a jit.off() jit.on() set, then
the code works as expected, never producing corrupted results. It also
works correctly with a jit.flush() as the first line in the loop. Running
the project with jit.opt.start(0) does not alleviate the issue either.
As a workaround, put the code in question into a function and use
jit.off(func) (once at startup). That only turns off JIT-compilation
for this function. The other calls apply globally and are not
really helpful.
How can I go about producing some more information to help?
Try to reduce it to a small standalone test case. That's the only
way to track it down.
From the way the symptoms look, this could be some GC64-related
issue with restoring the JIT-compiler state back to the Lua stack.
But that's just a wild guess.
[
Note that if you're using the FFI and change a project from 32 bit
to 64 bit, check that all data types are still valid and have the
expected sizes. Especially on Windows that's a giant mess, due to
the decision to keep 'long' as 32 bit. Various items that have
been traditionally declared as 'long' need to be re-declared to
the proper 32/64 bit type. The C headers shield you a bit from
this mess, but the FFI doesn't know about that.
FFI mis-declarations can cause overwrites of random parts of data,
even in unrelated code.
]
--Mike
Other related posts:
