Re: Memory Leak with CFSocket objects
Re: Memory Leak with CFSocket objects
- Subject: Re: Memory Leak with CFSocket objects
- From: Becky Willrich <email@hidden>
- Date: Tue, 18 Nov 2003 08:19:48 -0800
But still my object is not released. I used a call CFGetRetainCount to
get the reference count. For first call of CFSocketCreateWithNative,
it gives the count as two, for rest it's one.
Your code is correct and should not result in a leak. However, keep in
mind that CFGetRetainCount() will never return 0 - that would imply
that you had called CFGetRetainCount() on a deallocated object, which
would be Bad. If the object has already been dealloc'ed, usually
CFGetRetainCount() will either return the last valid answer (1), or it
will crash, same as any CF call on an invalid CFType. So if
CFGetRetainCount() returned 1 immediately before you called
CFRelease(), you can rest assured that the CFSocket has been truly
deallocated. You can verify by running with the environment variable
MallocScribble set to 1 - this will cause all freed bytes to be
scribbled over with 0x55 as soon as they are freed. With this variable
set, your program will crash if you call CFGetRetainCount() immediately
after calling the final CFRelease().
It's also possible that someone else has taken a retain of the CFSocket
- possibly the CFRunLoop which is dispatching your callback. It may
want to ensure that the CFSocket lives at least long enough for it to
do normal cleanup following the callback dispatch, for instance. If
this is the case, the CFSocket will likely be dealloc'ed before the run
loop returns all the way out. You can verify by running leaks at that
time, or by allocating the CFSocket from a custom allocator, so you can
track when the blocks of memory are freed.
Hope that helps,
REW
_______________________________________________
macnetworkprog mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/macnetworkprog
Do not post admin requests to the list. They will be ignored.