Re: segfault related to Qt on dlclose (linux)

[Peter Odding <peter@...>]

Hi Gaspard,

> Some of you might have a longer experience with Lua and Qt on Linux...
> 
> I am having a SEGFAULT during Lua close, probably when closing the Qt bindings library (loaded with require) but I don't really know where to look for the bug... ;-(
> 
> If anyone has an idea...
> 
> Gaspard
> 
> -------- GDB backtrace
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x013145f6 in ?? () from /usr/lib/i386-linux-gnu/libQtCore.so.4
> (gdb) bt
> #0  0x013145f6 in ?? () from /usr/lib/i386-linux-gnu/libQtCore.so.4
> #1  0x0131126c in QFactoryLoader::~QFactoryLoader() () from /usr/lib/i386-linux-gnu/libQtCore.so.4
> #2  0x01311302 in QFactoryLoader::~QFactoryLoader() () from /usr/lib/i386-linux-gnu/libQtCore.so.4
> #3  0x009143a8 in ?? () from /usr/lib/i386-linux-gnu/libQtGui.so.4
> #4  0x001e7d2b in __cxa_finalize () from /lib/i386-linux-gnu/libc.so.6
> #5  0x00842a94 in ?? () from /usr/lib/i386-linux-gnu/libQtGui.so.4
> #6  0x00f7846d in _fini () from /usr/lib/i386-linux-gnu/libQtGui.so.4
> #7  0x0000000e in ?? ()
> #8  0x0012eff4 in ?? () from /lib/ld-linux.so.2
> #9  0x00123b98 in ?? () from /lib/ld-linux.so.2
> #10 0x0016bcf2 in ?? () from /lib/i386-linux-gnu/libdl.so.2
> #11 0x0011e61f in ?? () from /lib/ld-linux.so.2
> #12 0x0016c33a in ?? () from /lib/i386-linux-gnu/libdl.so.2
> #13 0x0016bd28 in dlclose () from /lib/i386-linux-gnu/libdl.so.2
> #14 0x0805d77d in ll_unloadlib (lib=0x80a0270) at /home/gaspard/git/lubyk/modules/lk/src/lua/vendor/src/loadlib.c:64
> #15 0x0805d994 in gctm (L=0x807c008) at /home/gaspard/git/lubyk/modules/lk/src/lua/vendor/src/loadlib.c:288
> #16 0x08056773 in luaD_precall (L=0x807c008, func=0x8082c34, nresults=0)
>     at /home/gaspard/git/lubyk/modules/lk/src/lua/vendor/src/ldo.c:319
> #17 0x080569c2 in luaD_call (L=0x807c008, func=0x8082c34, nResults=0)
>     at /home/gaspard/git/lubyk/modules/lk/src/lua/vendor/src/ldo.c:376
> #18 0x08058f6d in GCTM (L=0x807c008) at /home/gaspard/git/lubyk/modules/lk/src/lua/vendor/src/lgc.c:467
> #19 0x08058f95 in luaC_callGCTM (L=0x807c008) at /home/gaspard/git/lubyk/modules/lk/src/lua/vendor/src/lgc.c:479
> #20 0x08064020 in callallgcTM (L=0x807c008, ud=0x0) at /home/gaspard/git/lubyk/modules/lk/src/lua/vendor/src/lstate.c:195
> #21 0x08055b77 in luaD_rawrunprotected (L=0x807c008, f=0x806400f <callallgcTM>, ud=0x0)
>     at /home/gaspard/git/lubyk/modules/lk/src/lua/vendor/src/ldo.c:116
> #22 0x080640cc in lua_close (L=0x807c008) at /home/gaspard/git/lubyk/modules/lk/src/lua/vendor/src/lstate.c:209

Not sure if you resolved this yet, if not maybe this will help: I think I've seen similar stack traces in Lua/APR back when I was still fighting with multithreading. In my case the problem always came down to the following:

 * Multiple operating system threads active at the same time, using the same dynamic libraries (*.so).

 * The main thread is supposed to be waiting for one of the child threads to finish, but instead the main thread encounters an error that bubbles all the way up to the main Lua interpreter loop, which terminates the process after printing an error message.

 * The main thread is now terminating while the child thread is still running, and I have the impression that this is generally not safe: I could not get it working reliably without joining all child threads in their __gc metamethod in the main thread and Lua state, without this segmentation faults would bite me every once in a while, i.e. the result was very non-deterministic.

So my suggestion is not at all related to Qt (I have absolutely no programming experience with Qt), but the stack traces I got were most definitely very similar.

Good luck!

 - Peter