Re: SIGSEGV in LuaJIT 2.1 VM
- From: Igor Ehrlich <igor.a.ehrlich@xxxxxxxxx>
- To: luajit@xxxxxxxxxxxxx
- Date: Fri, 18 Nov 2016 17:15:52 +0300
An alternative hypothesis is that the memory is seen as executable,
but the contents of the memory is still seen as 00 00 00 00 by the
executing CPU, which decodes as `add [eax], ax`, and would segfault
given that rax contained 0xC. That said, rapidly flipping page
protection causing confusion seems a more likely hypothesis.
You mean a fresh trace? I highly doubt that. In my studies, the failing
trace was not the overall last, and it was not even the last in its mcode
region.
There's an even longer shot. Considering what Tomas disclosed about his
infrastructure, he's most likely using cloud machines in either AWS or GCE
(I'll bet AWS, but that does not matter). We also experienced such failures
in the clouds, with weird patterns - for example, there could be a storm of
errors that would completely disappear after the next recycling (which
effectively proves that AWS is not completely fair about the host
architecture it exposes to guest systems, fun fact).
So, it might also be a bug in either the virtualization (which I doubt,
cause these are different in AWS and GCE), or the inconsistency between
host and guest machine layouts.
On Fri, Nov 18, 2016 at 4:51 PM, Peter Cawley <corsix@xxxxxxxxxx> wrote:
On Fri, Nov 18, 2016 at 1:43 PM, Igor Ehrlich <igor.a.ehrlich@xxxxxxxxx>
wrote:
Please note, you are most probably not experiencing the issue with
reading/writing. You are experiencing an issue with __executing__ the
code
that's right under your RIP (first instruction of the compiled trace).
Region mapping will show CODE attribute for it, but I believe it is not
that
way at the moment of execution within the hardware.
An alternative hypothesis is that the memory is seen as executable,
but the contents of the memory is still seen as 00 00 00 00 by the
executing CPU, which decodes as `add [eax], ax`, and would segfault
given that rax contained 0xC. That said, rapidly flipping page
protection causing confusion seems a more likely hypothesis.
Other related posts:
