Re: Debugging GNUstep app

[Andreas Höschler]

Hi David,

> > I only see that the run loop catched an exception. This does not help 
> > me a bit. I guess the exception was raised in a subthread.
>
> It shouldn't be.  Exceptions should be caught in the thread that they 
> are thrown.  I'm not sure how they'd be moved between threads.  If you 
> want to see where an exception is thrown, add a breakpoint on 
> -[NSException raise].

OK, I am receiving data on a socket in a subthread, then create a 
NSNotification and teleport that to the main thread using 
performSelectorOnMainThread:

   NSNotification *notification = [NSNotification 
notificationWithName:SRFileHandleReadCompletionNotification object:self 
userInfo:((data) ? [NSDictionary dictionaryWithObject:data 
forKey:SRFileHandleNotificationDataItem] : nil)];
	   [[NSNotificationCenter defaultCenter] 
performSelectorOnMainThread:@selector(postNotification:) 
withObject:notification waitUntilDone:YES];

gdb then gives me the following:

Thread 1 (process 84361    ):
#0  0xfe05a0b7 in _lwp_kill () from /lib/libc.so.1
#1  0xfe055814 in thr_kill () from /lib/libc.so.1
#2  0xfe001df3 in raise () from /lib/libc.so.1
#3  0xfdfe1c3d in abort () from /lib/libc.so.1
#4  0xfe308979 in _terminate () at NSException.m:686
#5  0xfe308b44 in _NSFoundationUncaughtExceptionHandler 
(exception=0xae91bc8) at NSException.m:710
#6  0xfe3091db in -[NSException raise] (self=0xae91bc8, 
_cmd=0xfef2f1a8) at NSException.m:841
#7  0xfecacaab in _NSAppKitUncaughtExceptionHandler 
(exception=0xae91bc8) at NSApplication.m:142
#8  0xfe3091cd in -[NSException raise] (self=0xae91bc8, 
_cmd=0xfe56cc68) at NSException.m:832
#9  0xfe3787d1 in -[NSRunLoop acceptInputForMode:beforeDate:] 
(self=0x83536f8, _cmd=0xfe56ccd8, mode=0xfe56cd68, limit_date=0x94aca30)
    at NSRunLoop.m:991
#10 0xfe378a46 in -[NSRunLoop runMode:beforeDate:] (self=0x83536f8, 
_cmd=0xfef6f858, mode=0xfe56cd68, date=0x8366f70) at NSRunLoop.m:1043
#11 0xfee1b27f in -[GSDisplayServer(EventOps) 
getEventMatchingMask:beforeDate:inMode:dequeue:] (self=0x8207528, 
_cmd=0xfd9fbc60,
    mask=4294967295, limit=0x8366f70, mode=0xfe56cd68, flag=1 '\001') 
at GSDisplayServer.m:971
#12 0xfd9909b5 in -[XGServer(X11Ops) 
getEventMatchingMask:beforeDate:inMode:dequeue:] (self=0x8207528, 
_cmd=0xfef2f178, mask=4294967295,
    limit=0x8366f70, mode=0xfe56cd68, flag=1 '\001') at 
XGServerEvent.m:2354
#13 0xfecb255e in DPSGetEvent (ctxt=0x8207528, mask=4294967295, 
limit=0x8366f70, mode=0xfe56cd68) at GSDisplayServer.h:180
#14 0xfecb2db5 in -[NSApplication 
nextEventMatchingMask:untilDate:inMode:dequeue:] (self=0x81fc3f8, 
_cmd=0xfef2f3c8, mask=4294967295,
    expiration=0x8366f70, mode=0xfe56cd68, flag=1 '\001') at 
NSApplication.m:2008
#15 0xfecb171d in -[NSApplication run] (self=0x81fc3f8, 
_cmd=0xfef2a968) at NSApplication.m:1452
#16 0xfec96648 in NSApplicationMain (argc=1, argv=0x8047738) at 
Functions.m:72
#17 0x08052242 in main (argc=1, argv=0x8047738, env=0x8047740) at 
SOObjectBrowser_main.m:35

The exception is raised in NSData::subdataWithRange due to an invalid 
specified range. Unfortunatelly the above back trace gives me no hint 
where exactly the error is raised, not even that is was in NSData.m. I 
only know that from NSException::reason. No clue, who is sending this 
invalid data packet and posts it to the main thread!?

The other thread looks like so:

Thread 2 (process 80431497    ):
#0  0xfe05738b in __lwp_park () from /lib/libc.so.1
#1  0xfe0519d3 in cond_sleep_queue () from /lib/libc.so.1
#2  0xfe051b8c in cond_wait_queue () from /lib/libc.so.1
#3  0xfe052060 in _cond_wait () from /lib/libc.so.1
#4  0xfe0520a2 in cond_wait () from /lib/libc.so.1
#5  0xfe0520db in pthread_cond_wait () from /lib/libc.so.1
#6  0xfe59ef63 in __objc_condition_wait (condition=0x4, mutex=0x4) at 
../gcc/gthr-posix.h:426
#7  0xfe59e826 in objc_condition_wait (condition=0x8a955b8, 
mutex=0xbf48308) at /usr/share/src/gcc-3.4.4/libobjc/thr.c:493
#8  0xfe333757 in -[NSConditionLock lockWhenCondition:] 
(self=0xaebac00, _cmd=0xfe571fb0, value=1) at NSLock.m:348
#9  0xfe3a1093 in -[NSObject(NSMainThreadPerformAdditions) 
performSelectorOnMainThread:withObject:waitUntilDone:modes:] 
(self=0x80cb288,
    _cmd=0xfe571fc0, aSelector=0xfe931948, anObject=0xaee42c8, aFlag=1 
'\001', anArray=0x8319478) at NSThread.m:1075
#10 0xfe3a1160 in -[NSObject(NSMainThreadPerformAdditions) 
performSelectorOnMainThread:withObject:waitUntilDone:] (self=0x80cb288,
    _cmd=0xfe931958, aSelector=0xfe931948, anObject=0xaee42c8, aFlag=1 
'\001') at NSThread.m:1093
#11 0xfe8dff24 in -[SRFileHandle _readInBackgroundAndNotifyThread] 
(self=0x8b5dad8, _cmd=0xfe931980) at SRFileHandle.m:612
#12 0xfe3477db in -[NSObject performSelector:withObject:] 
(self=0x8b5dad8, _cmd=0xfe571f00, aSelector=0xfe931980, anObject=0x0)
    at NSObject.m:1947
#13 0xfe3a0492 in -[NSThread _sendThreadMethod] (self=0xa471040, 
_cmd=0xfe571ee0) at NSThread.m:780
#14 0xfe59e67c in __objc_thread_detach_function (istate=0x4) at 
/usr/share/src/gcc-3.4.4/libobjc/thr.c:106
#15 0xfe057045 in _thr_setup () from /lib/libc.so.1
#16 0xfe057330 in L3_doit () from /lib/libc.so.1
#17 0xfd580a00 in ?? ()
#18 0x00000000 in ?? ()

I learn that -[SRFileHandle _readInBackgroundAndNotifyThread] sends 
then notification to the mainthread that causes trouble. But the 
problem happens only in 1 of 100 times and the above traces give me no 
further clue!


> > Any chance I can get a backtrace from a subthread in gdb? This might 
> > be a dummy/newbie question but I have never done that and figured out 
> > how this would work. Is that possible?
>
> If it is related to threads, then 'info threads' will list the 
> currently running threads and then thread {number} will switch gdb to 
> showing the numbered thread.

I have a clue what went wrong ...

Thanks for your "swithing thread" hint!

Regards,

 Andreas