I really wanted this patch to work, but in my tests, it does not work :
Here is my backtrace.
#0 0x939d4689 in _cache_getImp ()
#1 0x939c3bd0 in lookupMethodInClassAndLoadCache ()
#2 0x939c3c5b in object_cxxDestructFromClass ()
#3 0x939c4943 in _internal_object_dispose ()
#4 0x949f8f70 in NSDeallocateObject ()
#5 0x94a38570 in -[NSDistantObjectTableEntry dealloc] ()
#6 0x9156f5fa in CFRelease ()
#7 0x914fec8d in __CFArrayReleaseValues ()
#8 0x914ff00d in _CFArrayReplaceValues ()
#9 0x949faf6b in -[NSCFArray removeObjectAtIndex:] ()
#10 0x949fadd9 in -[NSMutableArray(NSMutableArray)
removeObjectsAtIndexes:] ()
#11 0x94a3829a in invalidateProxy ()
#12 0x94a38023 in -[NSDistantObject dealloc] ()
#13 0x949f4d9f in NSPopAutoreleasePool ()
#14 0x25404120 in -[GDOPKPeer _connectToRemotePeerWithDictionary:] ()
#15 0x949fa15c in __NSThreadPerformPerform ()
#16 0x9156d62e in CFRunLoopRunSpecific ()
#17 0x9156dd18 in CFRunLoopRunInMode ()
#18 0x94a2db15 in -[NSRunLoop(NSRunLoop) runMode:beforeDate:] ()
#19 0x25407bca in -[GDOPKPeer _startPeer] ()
Aurélien,
Objective Decision Team
On 27 mai 08, at 21:08, Guy Meyer wrote:
Welcome to the Leopard club. Yes there is DO code that works fine
with Tiger and faults on Leopard. The issue described below refers
to remote DO (i.e. socketports) as opposed to local DO.
What I have found (after spending many hours on the issue) is that
if there are multiple DO connections between the same addresses and
one of them is invalidated/ closed the result is that all of them
are faulting.
The reason for this behavior is that when an nsconnection dies the
socketport (which is also used by all other nsconnections to same
address - in order to save resources) is getting released twice !!!
( and on Tiger once). When the count reach zero the port is
invalidated/deallocated and all other nsconnections using said
socketport fail. Because of that the bug is not always reproducible
and appears to behave randomly - a nightmare.
It seems that on Leopard (as opposed to Tiger) the socketport is
observing the nsconnection and when it is closed and dies the
socketport receives a notification and its reference count is
decreased, beside some other code that decreases the count.
The solution is unbelievable simple (and I have found that there are
no memory management issues with this solution - but better test for
yourself). You should cancel the port observation of
NSConnectionDidDieNotification, just after creating the port, as
follows:
clientPort = (NSPort *)[[NSSocketPort alloc]
initRemoteWithProtocolFamily:PF_INET socketType:SOCK_STREAM
protocol:IPPROTO_TCP address:serverAddress];
[[NSNotificationCenter defaultCenter] removeObserver:clientPort
name:NSConnectionDidDieNotification object:nil];
The above code does not create a problem on Tiger as the socketport
is not observing NSConnectionDidDieNotification.
A bug was opened by ADC on my behalf in January <radr: //5706866>
It is a shame that a bug like this (which is neither fixed nor
publicly published) causes so many people to waste their time, but
this is a discussion for another list, I guess.
Update me if it works for you.
Guy Meyer
On May 27, 2008, at 2:41 AM, Ben Einstein wrote:
I, too, have encountered this nasty little problem on Leopard.
Works fine on Tiger, but I see this error followed by a nice crash
about 10% of time on my DO servers with Leopard. I have no idea
what's going on and why it's fine 80% of the time and not the other.
Alex/Aurélien, have you found a solution?
Thanks,
Ben Einstein
On Mar 25, 2008, at 9:12 AM, Aurélien Hugelé wrote:
I encountered this very same problem with DO since Leopard.
I noticed that a large part of the DO backend has been rewritten
in Leopard.
If you know how to fix/reproduce the problem, I'll be glad to know.
I suggest trying your program on a Tiger/Tiger configuration.. I'm
pretty sure it will work as expected.
Aurélien,
Objective Decision Team
On 19 mars 08, at 01:58, Alexander Cohen wrote:
Hi, i have a server and client communication through DO.
Connections are all set up then the client send a message to the
server with itself as the first argument. The server should then
just reply right away to the client using the first argument as
the proxy. Problem is, im getting the error below when trying to
send the response form the server back to the client. Any ideas
what might be happening?
server received hello
*** NSDistantObject initWithCoder: 0x2 not given away for conn
0x171a62f0
exceptionHandler:shouldHandleException:
-[NSConcretePortCoder decodeInvocation]: no local target
thanks
AC
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the
list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/hugele.aurelien%40objective-decision.com
This email sent to [EMAIL PROTECTED]
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/beinstein%40comcast.net
This email sent to [EMAIL PROTECTED]
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/rominar%40mac.com
This email sent to [EMAIL PROTECTED]
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/hugele.aurelien%40objective-decision.com
This email sent to [EMAIL PROTECTED]
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
