Re: Deallocating cocoa distant objects.
Re: Deallocating cocoa distant objects.
- Subject: Re: Deallocating cocoa distant objects.
- From: Ken Thomases <email@hidden>
- Date: Thu, 21 May 2009 22:41:00 -0500
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 (email@hidden)
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:
This email sent to email@hidden