[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Hanging multi-threaded tools
From: |
Richard Frith-Macdonald |
Subject: |
Re: Hanging multi-threaded tools |
Date: |
Wed, 5 Nov 2014 17:00:47 +0000 |
On 5 Nov 2014, at 15:16, 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!??
>
> Fixed! An exception was raised between lock and unlock in NSThread.m. I
> inserted NS_DURING, NS_HANLDER code to catch this and the problem is gone! :-)
Thanks ... after an off-line email exchange I realised that this problem was
with a version of gnustep dating back to the start of 2008 or earlier, and it
seems likely that this problem was fixed by changes made in March 2008.
So anyone using a version of the library released in the last five years
probably shouldn't have to worry about it.