Le samedi 22 janvier 2011 à 21:11 +0000, David Chisnall a écrit : > On 22 Jan 2011, at 20:54, Philippe Roussel wrote: > > > Hi all, > > > > In trying to understand why my application randomly blocks, I found that > > it always has 2 threads running and I don't know what the second one is > > for. > > > > It seems this thread is waiting on some condition lock : > > > > #0 0xb7fe2424 in __kernel_vsyscall () > > #1 0xb7428015 in pthread_cond_wait@@GLIBC_2.3.2 () at > > ../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/pthread_cond_wait.S:122 > > #2 0xb76639dd in __pthread_cond_wait (cond=0x80de870, mutex=0x80de858) at > > forward.c:139 > > #3 0xb771d14f in ?? () from > > /opt/GNUstep-trunk/Local/Library/Libraries/libobjc.so.4 > > Here, libobjc2 created this thread. It exists to do cleanup on some data > structures. > > > Once I saw my main thread blocked on the same condition/mutex (I think > > it was load_lock in NSBundle) : deadlock. > > It shouldn't ever be blocking on that lock. It's only ever used to > pass off work to the background thread's queue. If you're making a > huge number of changes to runtime data structures then you might end > up with this queue becoming full and the second thread having to do > some work before the first is allowed to proceed, but it's quite > unlikely. > > It's not exposed outside of the runtime, so I'm a bit surprised if > this is really the cause of your problem. This thread is expected to > spend almost all of its time asleep. If you have libdispatch > installed it won't exist at all.
Well, I must have misread the backtraces. The application blocks but it's not a deadlock with this libobjc2 thread, sorry about that. I'll have to dig deeper. > > I'm wondering if my code is responsible by doing too much work in > > +initialize methods (ie creating singleton). > > Nope, should be fine. Ok, thanks for the explanations David Philippe _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev