> On 1 Aug 2016, at 11:59, Ivan Vučica <i...@vucica.net> wrote: > > For context this is the first message in the thread: > http://lists.alioth.debian.org/pipermail/pkg-gnustep-maintainers/2016-July/003934.html > > On Mon, 1 Aug 2016, 11:32 Ivan Vučica, <i...@vucica.net> wrote: > Gdb backtrace is sort-of useful, but reading the code I can't tell where the > bug in leakAt: is. It seems to clean up its use of exitLock after itself. > > I will assume you wanted to send this to the list, and I will also cross post > this onto gnustep-dev. > > The curious part is "it works locally, but not on buildd" which you mentioned > earlier in the thread. Is the compiler different remotely? Does it reproduce > with the same compiler? > > On Mon, 1 Aug 2016, 10:44 Nicolas Boulenguez, <nico...@debian.org> wrote: > On Sun, Jul 31, 2016 at 11:49:03PM +0000, Ivan Vučica wrote: > > gdb: I meant, attach to it once it freezes and collect the backtrace. > I did not know that gdb could attach a running process. Thanks. > > #0 0x00007fdd098ebe9c in __lll_lock_wait () from > /lib/x86_64-linux-gnu/libpthread.so.0 > #1 0x00007fdd098e5b92 in pthread_mutex_lock () from > /lib/x86_64-linux-gnu/libpthread.so.0 > #2 0x00007fdd0bd115d5 in -[NSRecursiveLock lock] (self=0x55ab20a1a8d0, > _cmd=0x7fdd0c285d90 <_OBJC_SELECTOR_TABLE+144>) at NSLock.m:308 > #3 0x00007fdd0be20da9 in +[NSObject(GSCleanup) leakAt:] (self=<optimized > out>, _cmd=<optimized out>, anAddress=<optimized out>) at > NSObject+GNUstepBase.m:200 > #4 0x00007fdd0bd9731b in +[NSTimeZone initialize] (self=<optimized out>, > _cmd=<optimized out>) at NSTimeZone.m:1357 > #5 0x00007fdd0a0230d6 in __objc_install_dtable_for_class (cls=0x7fdd0c22cd40 > <_OBJC_MetaClass_NSTimeZone>) at > /build/gcc-6-SXl3Vx/gcc-6-6.1.1/src/libobjc/sendmsg.c:1030
I would guess this is a multi-threaded application and there's a deadlock between the two threads initialising various classes in an unusual order. The general workaround for that kind of thing is to have a single thread start things up first (eg have the main thread call [NSDate class] before the app goes multithreaded) to ensure that the deadlock can't occur. Maybe the problem doesn't occur on svn trunk because I recently changed the atExit handling code (used by -leakAt:) to use its own lock, rather than sharing the gnustep general lock, precisely so that registering things for cleanup at process exit will not block things initialising in another thread. In an ideal world multiple threads would not be able to deadlock during class initialisation, but the different runtimes have slightly different behaviors in the way they lock things during +initialize and I don't think it's always possible to write code that's safe with all runtimes ... so I think apps need to take some care to initialise things in a single thread (and +initialize and +load implementation shouldn't launch new threads themselves unless they are *sure* they aren't creating potential for deadlock). _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev