|
From: | Marcus Müller |
Subject: | Re: Help with gdb needed |
Date: | Thu, 31 Jan 2013 01:11:15 +0100 |
Hi, I have a bit more info on that bug available now, which seems to be a race condition. The bug occurs when two GSAvahiNetService instances are being removed from a GSAvahiNetServiceBrowser in rapid succession. (This probably doesn't occur for too many people out there, but I happen to have a server setup with two network interfaces and Avahi reflector enabled between both interfaces - thus it occurs to me very frequently). When a GSAvahiNetService is removed from a GSAvahiNetServiceBrowser, what happens is this: #0 -[GSAvahiWatcher dealloc] (self=0x806cee888, _cmd=0x801125f80 <.objc_selector_list+160>) at GSAvahiRunLoopIntegration.m:201 #1 0x0000000800c15849 in -[NSObject release] (self=0x806cee888, _cmd=0x8010c0910 <.objc_selector_list+512>) at NSObject.m:2075 #2 0x0000000800aa44e7 in -[GSMutableArray removeObject:] (self=0x806ced408, _cmd=0x80117a1b0 <.objc_selector_list+352>, anObject=0x806cee888) at GSArray.m:700 #3 0x0000000800d18be1 in -[GSAvahiRunLoopContext removeChild:] ( self=0x806cee648, _cmd=0x80117a0d0 <.objc_selector_list+128>, c=0x806cee888) at GSAvahiRunLoopIntegration.m:479 #4 0x0000000800d18c4c in -[GSAvahiRunLoopContext removeWatcher:] ( self=0x806cee648, _cmd=0x80117a130 <.objc_selector_list+224>, w=0x806cee888) at GSAvahiRunLoopIntegration.m:486 #5 0x0000000800d17747 in -[GSAvahiWatcher removeFromContext] ( self=0x806cee888, _cmd=0x80117a280 <.objc_selector_list+560>) at GSAvahiRunLoopIntegration.m:149 #6 0x0000000800d18735 in GSAvahiWatchFree (watch=0x806cee888) at GSAvahiRunLoopIntegration.m:355 #7 0x0000000801e00c35 in remove_watch () from /usr/local/lib/libavahi-client.so.3 #8 0x0000000805719a5b in ?? () from /usr/local/lib/libdbus-1.so.3 […] #13 0x0000000805704ae2 in ?? () from /usr/local/lib/libdbus-1.so.3 #14 0x0000000801df8efb in avahi_client_free () from /usr/local/lib/libavahi-client.so.3 #15 0x0000000800d166cd in -[GSAvahiClient freeClient] (self=0x806960888, _cmd=0x801178ef0 <.objc_selector_list+240>) at GSAvahiClient.m:151 #16 0x0000000800d16f49 in -[GSAvahiClient avahiClientDealloc] ( self=0x806960888, _cmd=0x801176ae0 <.objc_selector_list+288>) at GSAvahiClient.m:287 #17 0x0000000800d145b9 in -[GSAvahiNetService dealloc] (self=0x806960888, _cmd=0x801125f80 <.objc_selector_list+160>) at GSAvahiNetService.m:1956 Although it seems that the watcher removes itself from the runloop, the runloop crashes: #0 0x00000008011d34d0 in objc_msgSend_fpret () from /usr/local/lib/libobjc.so.4 #1 0x0000000800d6bdeb in -[GSRunLoopCtxt pollUntil:within:] ( self=0x80695f388, _cmd=0x80113c840 <.objc_selector_list+400>, milliseconds=19058, contexts=0x806ccc468) at GSRunLoopCtxt.m:639 #2 0x0000000800c60503 in -[NSRunLoop acceptInputForMode:beforeDate:] ( self=0x806ccd188, _cmd=0x80113ca70 <.objc_selector_list+960>, mode=0x80113c250 <.objc_str>, limit_date=0x806e03928) at NSRunLoop.m:1206 #3 0x0000000800c609d7 in -[NSRunLoop runMode:beforeDate:] (self=0x806ccd188, _cmd=0x80113ca00 <.objc_selector_list+848>, mode=0x80113c250 <.objc_str>, date=0x806e03848) at NSRunLoop.m:1274 Launching with NSZombieEnabled=YES reveals, that: 2013-01-30 22:35:46.373 XBellRinger[36118] *** -[GSAvahiWatcher receivedEvent:type:extra:forMode:]: message sent to deallocated instance 0x806cee888 Thus the assumption here seems to be wrong:
it looks as if the GSAvahiWatcher didn't properly remove itself from the runloop, although it's already been dealloced. I've stared for quite a while at [GSAvahiWatcher removeFromContext] but fail to see what's wrong there. Does anybody else have a clue? Cheers, Marcus -- Marcus Müller . . . http://www.mulle-kybernetik.com/znek/ |
smime.p7s
Description: S/MIME cryptographic signature
[Prev in Thread] | Current Thread | [Next in Thread] |