Hello,
I'm writing a Cocoa application which is running under Mac OS X 10.5.6
and it's using garbage collection. The application is compiled in gc-
supported mode (I'm aware that gc-only apps are the recommended
practice instead of gc-supported ones). The application uses a Carbon
view (HIViewRef) to display some textual information (in my situation
I'm forced to use Carbon views instead of Cocoa views for couple of
specific reasons).
I've been seeing the following errors in the console when the
application is run:
malloc: free_garbage: garbage ptr = 0x1bb9a60, has non-zero refcount = 2
malloc: free_garbage: garbage ptr = 0x1af55d0, has non-zero refcount = 1
malloc: free_garbage: garbage ptr = 0x1b5d740, has non-zero refcount = 3
malloc: *** free() called with 0x1bba4a0 with refcount 0
malloc: reference count underflow for 0x1bba4a0, break on
auto_refcount_underflow_error to debug.
malloc: free_garbage: garbage ptr = 0x1f43820, has non-zero refcount = 1
malloc: free_garbage: garbage ptr = 0x1f43990, has non-zero refcount = 1
malloc: *** free() called with 0x1b5e0a0 with refcount 0
malloc: reference count underflow for 0x1b5e0a0, break on
auto_refcount_underflow_error to debug.
malloc: *** error for object 0x1f437e0: Non-aligned pointer being
freed (2)
By setting a breakpoint to auto_refcount_underflow_error I've been
able to find out that these errors occur inside the -[NSCFString
finalize] method. By printing values on stack in gdb and using tools
like MallocStackLoggingNoCompact, malloc-history,
AUTO_RECORD_REFCOUNT_STACKS and auto_print_refcount_stacks() function
I've been able to deduce that the string which is being finalized is
created and used for the last time here:
NSString *string = [anObjCObject aMethodCreatingNSString]; // 'string'
is a local variable. 'aMethodCreatingNSString' is basically just
"return [NSString stringWithFormat:...];"
OSStatus status = SetControlData(control, kControlEntireControl,
kControlStaticTextCFStringTag, sizeof(CFStringRef), &string); // The
ControlKind of 'control' is kControlKindStaticText)
// 'string' is not referenced after these lines.
These errors do not occur every time this code is run - quite
contrary, to reproduce these errors I have to run this code usually
several hundreds times to get the first underflow or free_garbage error.
Documentation of SetControlData says that the passed-in data (i.e.
'string') is copied by this function, so the caller doesn't have to
retain it. I've tried replacing SetControlData() with HIViewSetText(),
with the same results. The code is compiled without optimizations, so
the local 'string' variable shouldn't be collected by GC even if GC
doesn't follow the void* argument of SetControlData() function in
which 'string' is passed.
By examining the refcount stacks printed by the
auto_print_refcount_stacks() function I can see that the refcount of
'string' is 1 right after it has been created by
CFAllocatorAllocate(), then it drops to 0 when CFMakeCollectible() is
called (by the Foundation framework), and then it goes up to 1 again
when it's passed to the SetControlData() function which calls
CFStringCreateCopy(), so everything seems correct here. But I'm still
getting those refcount underflows and free_garbage errors.
This problem seems to go away if I add CFRetain(string) and
CFRelease(string) around those two lines of code. However, since I
can't see why I should be using those functions here I'm feeling that
they're only masking the problem instead of fixing it.
Are there some issues I've not taken into account? Are there some GC-
incompatibility issues with Carbon I should be aware of? Which
debugging techniques should I use to investigate this further?
Best regards,
Nikita Zhuk
_______________________________________________
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
