Bit more on this. I don't think it even gets a chance to emit or run any
instructions at the point of crash, although I'm not totally sure here. I've
put a breakpoint at mcode_alloc_at() in lj_mcode.c and it is crashing before
hitting that.
Goin slowly step by step through the code points at cpcall() function messing
up the stack or something of a sort.
luajit [864294]
Thread [1] (STOPPED) (Suspended : Step)
cpcall() at lj_api.c:1,059 0x80502e0 <<<<- crashing on return from cpcall()
lj_vm_cpcall() at lj_vm.s:1,266 0x8060d90
lua_cpcall() at lj_api.c:1,074 0x8052f42
main() at luajit.c:566 0x804c0c0
static TValue *cpcall(lua_State *L, lua_CFunction func, void *ud)
{
GCfunc *fn = lj_func_newC(L, 0, getcurrenv(L));
fn->c.f = func;
setfuncV(L, L->top, fn);
setlightudV(L->top+1, checklightudptr(L, ud));
cframe_nres(L->cframe) = 1+0; /* Zero results. */
L->top += 2;
return L->top-1; /* Now call the newly allocated C function. */ <<<<-
crashing on return
}
Oleg
On 7 Aug 2018, at 12:34, Oleg Volosin
<oleg@xxxxxxxxxxxxxx<mailto:oleg@xxxxxxxxxxxxxx>> wrote:
Hi Mike
I tried to enable correct memory mapping for POSIX platforms (LUAJIT_OS_POSIX
macro) and confirmed mmap() in lj_mcode.c is actually invoked as it should. No
change, still crashing just as before.
I have also compared the LJ_TARGET_POSIX executable memory mapping code in
lj_mcode.c vs Google's V8 JITed engine which works OK on the platform (here
https://chromium.googlesource.com/v8/v8/+/3.27.27/src/platform-qnx.cc) and it
appears to be pretty much identical, i.e. it maps the region with (PROT_READ |
PROT_WRITE | PROT_EXEC) attributes.
Not totally sure where to move from here. Could you please advice.
I tried to gather some further debug info on this. It appears to crash on TSTEQ
instruction and I'm totally puzzled as to why:
Lua script:
print(">>>");
local times = 100;
while times > 0 do
times = times - 1;
end
print("<<<");
Call stack:
luajit [790566]
Thread [1] (STOPPED) (Suspended : Signal : SIGSEGV:Segmentation fault)
0x108d000 <<<<---- crashing on TSTEQ below ------------ <<<<
cache_one() at 0x1072bc4
0x31202020
0x31202020
DASM:
0108cfb8: andeq r0, r0, r1, lsl r0
0108cfbc: muleq r1, r8, r9
0108cfc0: andeq r0, r0, r2, lsl r0
0108cfc4: muleq r0, r0, pc ; <UNPREDICTABLE>
0108cfc8: andeq r0, r0, r3, lsl r0
0108cfcc: andeq r0, r0, r8
0108cfd0: svcvs 0x00fffffa
0108cfd4: andeq r0, r0, r5, asr #5
0108cfd8: andeq r0, r0, r0
0108cfdc: andeq r0, r0, r0
0108cfe0: andeq r0, r0, r0
0108cfe4: andeq r0, r0, r0
0108cfe8: andeq r0, r0, r0
0108cfec: andeq r0, r0, r0
0108cff0: andeq r0, r0, r0
0108cff4: andeq r0, r0, r0
0108cff8: andeq r0, r0, r0
0108cffc: andeq r0, r0, r0
0108d000: tsteq r8, r8, ror #30 <<<<---- crashing on TSTEQ ------------
<<<<
0108d004: stmdaeq r10, {r3, r4, r5, r7, r8, r9, r12, lr, pc}
0108d008: tsteq r1, r4, asr #4
0108d00c: tsteq r7, r12, lsr #10
0108d010: tsteq r4, r12, asr r1
0108d014: stmdavc r1, {r4, r6, r9, lr, pc}
0108d018: tsteq r4, r8, ror lr
0108d01c: smlabteq r5, r8, r0, r2
0108d020: smlabteq r3, r8, r3, sp
0108d024: stmdavc r1, {r0, r2, r4, r5, r6, r8, r11, r12, lr}
0108d028: tsteq r2, r12, lsl r11
0108d02c: tsteq r4, r12, asr #10
0108d030: ; <UNDEFINED> instruction: 0x0101efbc
0108d034: tsteq r5, r8, ror r3
0108d038: smlabteq r4, r4, sp, r5
0108d03c: ; <UNDEFINED> instruction: 0x01039f90
Regs:
r0 0xffffffff
r1 0x80c0370
r2 0x10a8
r3 0x2
r4 0x0
r5 0x80ae228
r6 0x80b5be8
r7 0x7
r8 0x80e0b58
r9 0x80e0ac8
r10 0x0
r11 0xe58de000
r12 0x108d6c8
sp 0x8047250
lr 0x1072bc4
pc 0x108d000
cpsr 0xa0000010
$
Oleg
On 6 Aug 2018, at 18:44, Mike Pall
<mikelj-1808@xxxxxxx<mailto:mikelj-1808@xxxxxxx>> wrote:
Oleg Volosin wrote:
Memory fault
Check memory page protections for JIT-compiled code. You're
probably ending up using the dummy allocator in lj_mcode.c, which
WILL fail, if memory is not executable by default.
In other words: Figure out which API your OS supports, e.g. POSIX.
Then compile with e.g. -DLUAJIT_OS=LUAJIT_OS_POSIX . Or contribute
a change to lj_arch.h for your OS (near LUAJIT_OS).
--Mike
