On May 21, 2009, at 4:01 PM, Santosh Sinha wrote:

I need your help with how to deallocate an object which is created in a server process A from a client process B.

In the project as we can see in the NSLog once the MyClass object is created and returned to the client, its retain count becomes 3. This causes the MyClass object to be refrained from getting deallocated even after releaseMyself is called.

Never attempt to debug memory management by inspecting retain counts. It will almost always lead you in the wrong direction.

For example, querying the remote object's retain count is very likely to give you a misleading answer. It's very likely that the object is retained an additional time during the handling of the inter-process request... for its retain count.

But that's just one example specific to this test. Inspecting retain counts is unhelpful even in the general case. For example, if an object has been retained and that's been balanced by an autorelease, the retain count will show an "extra" (seemingly unbalanced) retain even though the retain has been balanced. Etc., etc.

Use Instruments and/or logging in -dealloc to determine if objects really are being deallocated when (or at least soon after) you think they should be.


Also, in the function call setString:(MutableString**). I think I am doing straightforward in client by allocating it in Client, setting its content in Server and then deallocating it in Client after I have used it but the release of the allocated string in the client results in a crash when the local release pool is popped out.

First, why are you using double indirection in that method? Why not just pass the mutable string object byref (the default) and then invoke -setString: on it? (Well, of course, the simpler way of implementing that would be to simply request a string from the remote object rather than asking the remote object to modify an already existing string, but I assume you're presenting a simplified case for some other case.)

Then, there's no way for us to know why you're getting a crash when the autorelease pool is popped until you identify what's actually happening. Is there a Cocoa exception? If so, what exception? Is it a kernel exception or signal? If so, what? On what object was the autorelease pool acting? Who allocated it? Have you used Instruments to trace the retain/release history of that object? Have you tried NSZombieEnabled?

Lastly, it's very possible there are memory management bugs in Distributed Objects. If you feel you've identified one, submit a bug report to Apple.

Regards,
Ken

_______________________________________________

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 arch...@mail-archive.com

Reply via email to