Re: [Debian GNUstep maintainers] request for help: oolite

[Richard Frith-Macdonald]

> On 1 Aug 2016, at 11:59, Ivan Vučica <address@hidden> 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, <address@hidden> 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, <address@hidden> 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).