Re: [LuaJIT] Segmentation Faults When GC'ing

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

Okay, so I've installed Linux+Valgrind but I can't compile LuaJIT in 32bit mode for it to use the system allocator because Ubuntu doesn't provide the debug-symbols-included version of glibc for 32bit programs and Valgrind depends on those for redirections. Nevertheless, after fixing up the program I got it to run on the 64 bit compiled LuaJIT, but Valgrind isn't reporting any writes to illegal sections of memory, even when I know it is:

$ valgrind ./luajit
==4830== Memcheck, a memory error detector
==4830== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==4830== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==4830== Command: ./luajit
==4830==
LuaJIT 2.0.0-beta9 -- Copyright (C) 2005-2012 Mike Pall. http://luajit.org/
JIT: ON CMOV SSE2 SSE3 SSE4.1 fold cse dce fwd dse narrow loop abc fuse
> ffi = require "ffi"
> bytearr = ffi.new("uint8_t[?]",10)
> bytearr[10] = 5
-- No errors here, what?
> os.exit()
==4830==
==4830== HEAP SUMMARY:
==4830==     in use at exit: 0 bytes in 0 blocks
==4830==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==4830==
==4830== All heap blocks were freed -- no leaks are possible
==4830==
==4830== For counts of detected and suppressed errors, rerun with: -v
==4830== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)

But it will detect a test C program that does the same thing.

Do I need to compile LuaJIT to use the system allocator to detect buffer overruns?
(Yes I compiled LuaJIT with the valgrind option. Also the GDB JIT stuff should work now that I'm on Linux, correct?)

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