The reason why this question was not answered on SO is because either
no-one either knows about it or does not know about it's nature. However,
it's been in LuaJIT since forever (all 2.0 and 2.1 releases), but I
seriously doubt anyone approached it close enough.
Is far as I was able to investigate, this issue occurs very rarely when you
run LuaJIT in an x86_64 multi-core environments (recent architectures,
usually core-i5 for some reason) without thread affinity, constant memory
permission flapping causes hardware to malfunction and the application
fails. Possible solutions here are:
* use unprotected mcode;
* apply thread affinity for threads running LuaJIT;
BTW, sections layout in the core file will most probably be fine, because
it's a hardware issue. Due to its nature, it's very hard to reproduce in
any other way than with brute force, but even if you do reproduce it, it
will be very hard to catch the right point to debug it.
So far, it was the hardest debugging challenge for me among all other
things happening to LuaJIT :)
On Fri, Nov 18, 2016 at 3:18 PM, Peter Cawley <corsix@xxxxxxxxxx> wrote:
Your `maintenance info sections` output tells us the protection of
0x198f6f7d. Could you also tell us the protection of 0x401bb410? (My
hypothesis being that someone mprotect'ed your lua_State [1] to
read-only, but I don't know who or why)
[1] Actually one of the structures allocated alongside the initial
lua_State, but I digress.
On Fri, Nov 18, 2016 at 11:58 AM, Tomas Kvasnicka <nzt4567@xxxxxxx> wrote:
Hi,my chances over here. Commit ID is 7a58a8fb3d3d5808c54d096ab772113bf9024ae8
I’ve already tried asking at stackoverflow with no response so I’ll try
but it has been happening on previous versions of branch 2.1 as well.
Architecture is x86_64, detailed description is at
http://stackoverflow.com/questions/40609455/why-is-
this-mov-causing-a-sigsegv and generally any advice is appreciated. I’ve
been struggling with this for a couple of days with no luck so I’ll be glad
for any help.
Thanks,
Tomas
