Re: Hanging multi-threaded tools

[Richard Frith-Macdonald]

On 3 Nov 2014, at 15:53, Andreas Höschler <ahoesch@smartsoft.de> wrote:
> 
> Hi all,
> 
> I still have problems with multi-threaded tools that run into the following 
> trap on a regular basis:
> 
> #0  0xfdd78aab in __lwp_park () from /lib/libc.so.1
> #1  0xfdd718f3 in mutex_lock_queue () from /lib/libc.so.1
> #2  0xfdd7225c in mutex_lock_impl () from /lib/libc.so.1
> #3  0xfdd72335 in pthread_mutex_lock () from /lib/libc.so.1
> #4  0xfed9f36a in __objc_mutex_lock (mutex=0x4d) at ../gcc/gthr-posix.h:95
> #5  0xfed9ea23 in objc_mutex_lock (mutex=0x81d27f0) at 
> /usr/share/src/gcc-3.4.4/libobjc/thr.c:326
> #6  0xfdf4d3b8 in -[NSLock lock] (self=0x81d2780, _cmd=0xfe1edcc0) at 
> NSLock.m:241
> #7  0xfdfba858 in +[GSPerformHolder receivedEvent:type:extra:forMode:] 
> (self=0xfe1ed940, _cmd=0xfe2029a0, 
>    data=0x5, type=ET_RDESC, extra=0x5, mode=0xfe1e8ae8) at NSThread.m:918
> #8  0xfe031317 in -[GSRunLoopCtxt pollUntil:within:] (self=0x81c8568, 
> _cmd=0xfe1e8a30, milliseconds=283988, 
>    contexts=0x82256a8) at GSRunLoopCtxt.m:585
> #9  0xfdf92567 in -[NSRunLoop acceptInputForMode:beforeDate:] 
> (self=0x82273b0, _cmd=0xfe1e8a58, 
>    mode=0xfe1e8ae8, limit_date=0x81d9cc8) at NSRunLoop.m:969
> #10 0xfdf9290c in -[NSRunLoop runMode:beforeDate:] (self=0x82273b0, 
> _cmd=0xfe1e8a68, mode=0xfe1e8ae8, 
>    date=0x81f29f0) at NSRunLoop.m:1043
> #11 0xfdf92a92 in -[NSRunLoop runUntilDate:] (self=0x82273b0, 
> _cmd=0xfe1e8a60, date=0x81f29f0)
>    at NSRunLoop.m:1074
> #12 0xfdf929a7 in -[NSRunLoop run] (self=0x82273b0, _cmd=0x806bfc8) at 
> NSRunLoop.m:1057
> #13 0x08056e7d in main (argc=1, argv=0x8047788) at main.m:24
> 
> Any idea what this might be caused by? This is all pure GNUstep code!? I am 
> wondering what I might have done wrong!??
> 
> Hints greatly appreciated!!

Look at NSThread.m ... GSPerformHolder is used to handle performing a selector 
in another thread ... I guess it might be blocking waiting for the other thread 
to perform the selector ... or there could be a bug in the logic for that I 
suppose.
The basic idea is that to perform a selector in another thread, that other 
thread must have a run loop to perform the selector ... so we write to a pipe 
to wake the run loop.