Re: NSRunLoop busy wait problem

[Stephen Brandon]

ok, I have looked at this further, and see that there seems to be a deadlock 
bug in NSLog, at least in a given situation. If I replace the NSLog call with 
fprintf(stderr...) then it works ok.

Here's the situation:

- in a background thread I ask a Snd object to remove a SndPerformance from a 
holder array. There is a lock around this operation.
- _i_GSMutableArray__removeObject_ 
- _i_SndPerformance__isEqual_  (my user-defined method)
- NSLog(@"")
- this ends up in NSLog.m:160  ( RELEASE(arp);)
- in releasing one of the objects in NSLog's autorelease pool (I can't 
identify which one), there is a thread deadlock - see trace below.
- because of the nature of my app, this then causes a further deadlock of my 
main thread if I hit the "play" button again.

Cheers,
Stephen

On Wednesday 20 February 2002 12:48, Stephen Brandon wrote:
> Tracing my bug a little further - a deadlock condition has occurred in a
> NSLog statement inside a -compare method. We have various locks on
> different objects, so it's possible one of those is involved, but I'm not
> convinced. But looking through all the recent gnustep-base changes I can't
> see what would have triggered it. But the logging was working perfectly
> last night before my gnustep cvs update this morning.
>
> [performancesArray removeObject: p];
> calls:  _i_GSMutableArray__removeObject_
> calls: _i_SndPerformance__isEqual_
> which contains my debug statement: NSLog(@"checking if equal %@ vs. %@ =
> %s\n", self, anotherPerformance, equal ? "YES" :"NO");
>
> and from there:
>
> #0  0x407aab85 in __sigsuspend (set=0x41be950c) at
> ../sysdeps/unix/sysv/linux/sigsuspend.c:45
> #1  0x4076c1c9 in __pthread_wait_for_restart_signal (self=0x41be9be0) at
> pthread.c:969
> #2  0x4076df09 in __pthread_alt_lock (lock=0x80c8200, self=0x0) at
> restart.h:34
> #3  0x4076ad16 in __pthread_mutex_lock (mutex=0x80c81f0) at mutex.c:120
> #4  0x4066e47f in __objc_mutex_lock ()
>    from /usr/GNUstep/System/Libraries/ix86/linux-gnu/libobjc.so.1
> #5  0x4066e9d9 in objc_mutex_lock ()
>    from /usr/GNUstep/System/Libraries/ix86/linux-gnu/libobjc.so.1
> #6  0x4058137f in _i_NSRecursiveLock__lock (self=0x80c6f90,
> _cmd=0x40659420) at NSLock.m:543
> #7  0x405d8b6b in NSZoneFromPointer ()
>    from
> /usr/GNUstep/System/Libraries/ix86/linux-gnu/gnu-gnu-gnu/libgnustep-base.so
>.1 #8  0x405145de in _i_GSString__dealloc ()
>    from
> /usr/GNUstep/System/Libraries/ix86/linux-gnu/gnu-gnu-gnu/libgnustep-base.so
>.1 #9  0x405917ce in _i_NSObject__release (self=0x80e51a0, _cmd=0x40633130)
> at NSObject.m:1081
> #10 0x4053f413 in _i_NSAutoreleasePool__dealloc ()
>    from
> /usr/GNUstep/System/Libraries/ix86/linux-gnu/gnu-gnu-gnu/libgnustep-base.so
>.1 #11 0x4053f37e in _i_NSAutoreleasePool__release ()
>    from
> /usr/GNUstep/System/Libraries/ix86/linux-gnu/gnu-gnu-gnu/libgnustep-base.so
>.1 #12 0x40581852 in NSLogv (format=0x40366adc, args=0x41be9830) at
> NSLog.m:160 #13 0x4058158c in NSLog (format=0x40366adc) at NSLog.m:109