IB crashes while adding BGHUDAppKit widgets

[JanX2]

Whenever I try to add a BGHUDAppKit widget to the X-Tunes Overlay window IB crashes.

You can get a copy of the source it's happening with using this command: svn checkout http://x-tunes.googlecode.com/svn/branches/appscript-switch --revision 57 appscript-switch

You can find the window in MainMenu.xib

This also happens to me in a fresh project using XCode 3.2.1, Interface Builder 3.2.1 on Mac OS X 10.6.2.

I could narrow the crashing down: it happens when adding a widget based on NSCell or NSActionCell.

[JanX2]

This might be of help. Maybe not though ;)

Process: Interface Builder [13346] Path: /Developer/Applications/Interface Builder.app/Contents/MacOS/Interface Builder Identifier: com.apple.InterfaceBuilder3 Version: 3.2.1 (740) Build Info: InterfaceBuilder-7400000~3 Code Type: X86-64 (Native) Parent Process: launchd [137]

PlugIn Path: /Volumes/Development/Projects/X-Tunes/appscript-switch/BGHUDAppKit/BGHUDAppKit.framework/Versions/A/BGHUDAppKit PlugIn Identifier: com.binarymethod.BGHUDAppKit PlugIn Version: ??? (1.0)

Date/Time: 2010-03-28 00:27:47.646 +0100 OS Version: Mac OS X 10.6.2 (10C540) Report Version: 6

Interval Since Last Report: 106904 sec Crashes Since Last Report: 115 Per-App Interval Since Last Report: 68642 sec Per-App Crashes Since Last Report: 14 Anonymous UUID: 4ECCEE2D-6A51-428A-B7EE-7E6A17589DAB

Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: 0x000000000000000d, 0x0000000000000000 Crashed Thread: 0 Dispatch queue: com.apple.main-thread

Application Specific Information: objc_msgSend() selector name: release

Thread 0 Crashed: Dispatch queue: com.apple.main-thread 0 libobjc.A.dylib 0x00007fff820fd340 objc_msgSend_vtable14 + 16 1 com.binarymethod.BGHUDAppKit 0x00000001192b0eca -[BGHUDSegmentedCell dealloc] + 36 2 com.apple.CoreFoundation 0x00007fff81550246 _CFAutoreleasePoolPop + 230 3 com.apple.Foundation 0x00007fff8405c2f8 -[NSAutoreleasePool drain] + 158 4 com.apple.DevToolsKit 0x000000010005a0fe DTTrackDragging + 6590 5 com.apple.DevToolsKit 0x0000000100057eb6 -[DTDragManager dragImage:at:offset:mouseDownEvent:mouseDraggedEvent:pasteboard:allowedOperations:source:slideBack:draggingSourceContext:] + 62 6 com.apple.DevToolsKit 0x0000000100047829 -[DTAssetCategoryController(DTAssetCategoryControllerDragAndDrop) dragAssetPairs:withMouseDownEvent:mouseDraggedEvent:initialDraggedImageState:allowedOperations:imageLocationInWindow:] + 595 7 com.apple.DevToolsKit 0x0000000100049a83 -[DTAssetCategoryController(DTAssetCategoryControllerDragAndDrop) groupedTileViewDragSelectedItems:withMouseDownEvent:andMouseDraggedEvent:] + 667 8 com.apple.DevToolsKit 0x000000010002158e -[DTAssetLibrary groupedTileViewDragSelectedItems:withMouseDownEvent:andMouseDraggedEvent:] + 60 9 com.apple.DevToolsKit 0x000000010003bfcc -[DTGroupedTileView mouseDragged:] + 134 10 com.apple.AppKit 0x00007fff802eb3af -[NSWindow sendEvent:] + 8769 11 com.apple.AppKit 0x00007fff8021fe22 -[NSApplication sendEvent:] + 4719 12 com.apple.InterfaceBuilder3 0x00000001000038ad 0x100000000 + 14509 13 com.apple.AppKit 0x00007fff801b6796 -[NSApplication run] + 474 14 com.apple.AppKit 0x00007fff801af468 NSApplicationMain + 364 15 com.apple.InterfaceBuilder3 0x00000001000016a5 0x100000000 + 5797 16 com.apple.InterfaceBuilder3 0x0000000100001634 0x100000000 + 5684

Thread 1: Dispatch queue: com.apple.libdispatch-manager 0 libSystem.B.dylib 0x00007fff81158bba kevent + 10 1 libSystem.B.dylib 0x00007fff8115aa85 _dispatch_mgr_invoke + 154 2 libSystem.B.dylib 0x00007fff8115a75c _dispatch_queue_invoke + 185 3 libSystem.B.dylib 0x00007fff8115a286 _dispatch_worker_thread2 + 244 4 libSystem.B.dylib 0x00007fff81159bb8 _pthread_wqthread + 353 5 libSystem.B.dylib 0x00007fff81159a55 start_wqthread + 13

Thread 2: 0 libSystem.B.dylib 0x00007fff811599da __workq_kernreturn + 10 1 libSystem.B.dylib 0x00007fff81159dec _pthread_wqthread + 917 2 libSystem.B.dylib 0x00007fff81159a55 start_wqthread + 13

Thread 3: JavaScriptCore: FastMalloc scavenger 0 libSystem.B.dylib 0x00007fff8117a9ee __semwait_signal + 10 1 libSystem.B.dylib 0x00007fff8117e7f1 _pthread_cond_wait + 1286 2 com.apple.JavaScriptCore 0x00007fff80faf513 WTF::TCMalloc_PageHeap::scavengerThread() + 515 3 com.apple.JavaScriptCore 0x00007fff80faf559 WTF::TCMalloc_PageHeap::runScavengerThread(void*) + 9 4 libSystem.B.dylib 0x00007fff81178f8e _pthread_start + 331 5 libSystem.B.dylib 0x00007fff81178e41 thread_start + 13

Thread 0 crashed with X86 Thread State (64-bit): rax: 0x00000000000000a0 rbx: 0x0000000118b4de00 rcx: 0x0000000000000435 rdx: 0x00000000ffffffff rdi: 0x0000000116aaeb60 rsi: 0x00007fff808e1558 rbp: 0x00007fff5fbfee30 rsp: 0x00007fff5fbfee08 r8: 0x00007fff702f3260 r9: 0x0000000000000000 r10: 0x0000000116a83191 r11: 0x003ff00000000000 r12: 0x000000010117f200 r13: 0x000000010117f200 r14: 0x00007fff7031d3a0 r15: 0x0000000000000000 rip: 0x00007fff820fd340 rfl: 0x0000000000010206 cr2: 0x0000000114e23000

[regexident]

I can confirm this behaviour. It doesn't happen with all elements though. And in my experience not 100% of the time.

[JanX2]

You can get it to happen 100% of the time with the elements it does happen with: as soon as the alignment helpers appear IB will crash.

[JanX2]

After looking a bit deeper into this I came to the conclusion that this is a zombie infestation. I am not joking even though it is April, 2. It probably is an over-release of, in the case above, a BGHUDSegmentedCell. The next step is to identify where exactly we are falsely releasing the probably previously autoreleased BGHUDSegmentedCell.

[JanX2]

After using Instruments to check for zombies I found that this may not happen directly because of an actual bug in the code BGHUD but rather in the assumptions made. According to http://www.cocoadev.com/index.pl?SubclassingNSButtonCell we can't really know how e.g. "NSActionCell? implements -copyWithZone".

[JanX2]

After disabling all the code in BGHUDSegmentedCell the IB crashes persist. So the crashes probably are not the result of implementation details in BGHUDSegmentedCell.

[JanX2]

This may be of interest, too: http://www.cocoadev.com/index.pl?SingletonDesignPattern The suggestions there have no effect whatsoever on the issue at hand, though.

[timthedevguy]

Thanks for the report, thanks for all the info, I've been out of town for a week and unable to respond. I'm definitely going to look into this tom after work. (Just did a clean SL install and am currently setting up my environment)

[timthedevguy]

I can confirm this report, I just upgraded to the latest XCode/IB and I crash as well. This issue is taking top priority.

[timthedevguy]

Not sure why it didn't post the commit message here, but this was caused by a previous commit that added a call to release the themekey on every HUD control on dealloc. I believe this was in error as the themekey was declared with @property (retain) and I think that it's taken care of automatically when using @property.

[JanX2]

Working now. Thanks!

[timthedevguy]

So the actual problem was fixed..BUUT..it reintroduced the problem of themeKey being leaked. I need your guys help, I found out why it's failing, check out BGHUDComboBoxCell.m at line #71, if I replace that line with self.themeKey = @"someThemeKey" then all works as expected, I'm thinking it has something to do with retain releases....

I ran a zombie on it and it supports that theory but for the life of me I have no idea what is going wrong. Here's an image of the zombie result.

http://www.binarymethod.com/images/zombie.png

[JanX2]

It appears that in

self.themeKey = [aDecoder decodeObjectForKey: @"themeKey"];

the resulting NSString is retain-autoreleased and then retained again (via the self.themeKey) while

@"gradientTheme"

seems to ignores any retain/release messages.

We could try

self.themeKey = [[aDecoder decodeObjectForKey: @"themeKey"] retain];

but I can't tell where to balance that as the setter does that for us in a balanced manner and that should be enough.

[timthedevguy]

Ok, so I'm not crazy...thats what I thought too JanX2, but it still fails. I've even gone as far as creating my own accessors just incase it was something odd ball in properties, still no go. I've even enlisted help from the folks over at #macdev IRC and we have no ideas, I'm still working on it though, thanks for the help!! :)

[JanX2]

1. It is at least conceivable that this is not a bug in our domain, but in the a system frameworks'.
2. If it's just a single zombie it may be actually be a constant string. All objects appear to be kept on the heap.
3. Ask Apple
4. Disassemble the relevant portion of the framework responsible for NSComboBoxCell and have a look at how "the pros" do it ;)

[JanX2]

I just read through the cocotron implementation of NSComboBoxCell. They do this:

-initWithCoder:(NSCoder *)coder {
    [super initWithCoder:coder];
...
    _dataSource=[[keyed decodeObjectForKey:@"NSDataSource"] retain];
...
}

-(void)dealloc {
    [_dataSource release];
...
    [super dealloc];
}

-dataSource {
    return _dataSource;
}

-(void)setDataSource:value {
    _dataSource=value;
}

[timthedevguy]

Thanks JanX2, I've tried that as well. I did notice something though, the IBPlugin (without the release) works fine but leaks very bad. BUT, an application that is compile with NO GC doesn't leak at all. An application compiled with the release and GC turned OFF still doesn't leak. It seems that this is just an IB leak problem. Unfortunately I just upgraded both my machines XCode/IB so I can't test the theory that it might be IB.

[JanX2]

I have an older machine with 10.5.8 and Xcode 3.1.x. Should I just run Instruments on IB with an open BGHUD xib?

[timthedevguy]

Try adding a [themeKey release] line into one of the non-NSView based HUD controls, compile and see if the plugin will work in IB.

[timthedevguy]

ooops, add the release into dealloc, sorry

[JanX2]

IB 3.1.2 crashes just the same when I add the [themeKey release] line into dealloc.

[timthedevguy]

hrmm...thanks for testing that. Obviously there is something that I'm just not understanding. By all accounts themeKey should be released manually in dealloc, but this breaks it and no leaks are detected without it....this is just weird. Well I appreciate the help :)

[JanX2]

What about trying the approach that the cocotron is using? Instead of retain/release for the setter just copy the pointer...

[timthedevguy]

It produces the same results, I did it like this;

-initWithCoder... themeKey = [[coder decodeObjectForKey: @"themeKey"] retain];

-dealloc [themeKey release];