Re: [LuaJIT] Segmentation Faults When GC'ing

[Alex <initrd.gz@...>]

Okay, I've recompiled LuaJIT to use the system allocator. The program now throws breakpoint traps at points during the GC:

[New Thread 4688.0xfc4]

... server output, shuts down normally ...

warning: HEAP[luajit.exe]:

warning: Heap block at 00605D80 modified at 00605DA8 past requested size of 20

Program received signal SIGTRAP, Trace/breakpoint trap.

0x771f04e5 in ntdll!TpWaitForAlpcCompletion () from C:\windows\system32\ntdll.dll

(gdb) bt

#0  0x771f04e5 in ntdll!TpWaitForAlpcCompletion () from C:\windows\system32\ntdll.dll

#1  0x0028fc70 in ?? ()

#2  0x771d5732 in ntdll!RtlLargeIntegerDivide () from C:\windows\system32\ntdll.dll

#3  0x00605d80 in ?? ()

#4  0x771b29fa in ntdll!RtlCopyExtendedContext () from C:\windows\system32\ntdll.dll

#5  0x00000000 in ?? ()

(gdb) continue

Continuing.

warning: HEAP[luajit.exe]:

warning: Invalid address specified to RtlFreeHeap( 00470000, 00605D88 )

Program received signal SIGTRAP, Trace/breakpoint trap.

0x771f04e5 in ntdll!TpWaitForAlpcCompletion () from C:\windows\system32\ntdll.dll

(gdb) bt

#0  0x771f04e5 in ntdll!TpWaitForAlpcCompletion () from C:\windows\system32\ntdll.dll

#1  0x0028fc90 in ?? ()

#2  0x771b2a2a in ntdll!RtlCopyExtendedContext () from C:\windows\system32\ntdll.dll

#3  0x00605d80 in ?? ()

#4  0x771f153f in ntdll!TpQueryPoolStackInformation () from C:\windows\system32\ntdll.dll

#5  0x00470000 in ?? ()

#6  0x771aab9a in ntdll!AlpcMaxAllowedMessageLength () from C:\windows\system32\ntdll.dll

#7  0x00470000 in ?? ()

#8  0x77153492 in ntdll!LdrLoadAlternateResourceModuleEx () from C:\windows\system32\ntdll.dll

#9  0x00605d80 in ?? ()

#10 0x766a98cd in msvcrt!free () from C:\windows\syswow64\msvcrt.dll

#11 0x00470000 in ?? ()

#12 0x66dc8db8 in mem_alloc (ud=0x0, ptr=0x605d88, osize=32, nsize=0) at lib_aux.c:333

#13 0x66dbe01c in lj_mem_free (osize=<optimized out>, p=<optimized out>, g=<optimized out>) at lj_gc.h:119

#14 @lj_cdata_free@8 (g=<optimized out>, cd=<optimized out>) at lj_cdata.c:75

#15 0x66d849db in gc_sweep (g=0x473000, p=0x473024, lim=<optimized out>) at lj_gc.c:404

#16 0x66d8596c in lj_gc_freeall (g=0x473000) at lj_gc.c:558

#17 0x66d8c4dd in close_state (L=0x472fd0) at lj_state.c:159

#18 0x00403137 in main (argc=2, argv=0x472fa8) at luajit.c:555

(gdb) kill

Kill the program being debugged? (y or n) y

(gdb) quit

I should be able to run the project under Linux/Valgrind, since all of the libraries I'm using are portable; I just need to install Linux on one of my machines. Other than that, is there anything else I can do to debug?

On Tue, Apr 24, 2012 at 10:08 AM, Mike Pall <mikelu-1204@mike.de> wrote:

Alex wrote:
> Hi again. I'm having issues closing my server program. It's causing a
> segfault in the GC with the following backtrace:
>
> #0  0x66dcaee1 in lj_alloc_free (msp=0x2b0008, ptr=<optimized out>) at
> lj_alloc.c:1268

This looks like a buffer overrun, which corrupts the free lists of
the memory allocator. One possible cause is misuse of the FFI
(0-based vs. 1-based array mixup).

First, try using the system memory allcator, which often has some
extra debug options.

Or try Valgrind, except ...

> Win7 x64 (but compiled with -m32), compiled with asserts, debug info, and
> gdb jit stuff.

... Valgrind doesn't run on Windows.

And in fact the GDB JIT stuff only works on ELF targets, so you
might as well disable it. But I don't think it should cause a
crash, except when GDB tries to access the JIT symbols. The bogus
notifications from GDB in your other message indicate it doesn't
handle that very well.

--Mike