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:
> GSRunLoopCtxt.m:639 looks like this:
>
> /*
> * The watcher is still valid - so call its
> * receivers event handling method.
> */
> [watcher->receiver receivedEvent: watcher->data
> type: watcher->type
> extra: (void*)(uintptr_t)fd
> forMode: mode];
>
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
_______________________________________________ Gnustep-dev mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnustep-dev
