[Ghoser777]

So I'm working on updating my program Dockless, and I have 2 users who have a crash that I can't figure out. What's maddening is that they seem to have the same set up as I do (Leopard 10.5.5 on an Intel laptop). Here's my stack trace, and it's dying when a window is trying to be opened. I am very confused... any ideas of how to investigate this problem?

Code:
Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x00000000ffffffff
Crashed Thread:  0

Thread 0 Crashed:
0   com.apple.coreui              	0x96b31649 CUIElement::CUIElement(float) + 299
1   com.apple.coreui              	0x96b203a7 CUIRenderer::Draw1Piece(long, CUIContext const*, unsigned char, unsigned char) + 49
2   com.apple.coreui              	0x96b22851 CUIRenderer::Draw(CGRect, CGContext*, __CFDictionary const*, __CFDictionary const**) + 2257
3   com.apple.AppKit              	0x95697325 -[_NSThemeWidgetCell coreUIDrawWithFrame:inView:] + 276
4   com.apple.AppKit              	0x95697087 -[_NSThemeWidgetCell drawWithFrame:inView:] + 240
5   com.apple.AppKit              	0x95696b6b -[NSControl drawRect:] + 378
6   com.apple.AppKit              	0x9572a864 -[NSView _drawRect:clip:] + 3853
7   com.apple.AppKit              	0x9572935b -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] + 1050
8   com.apple.AppKit              	0x957296f2 -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] + 1969
9   com.apple.AppKit              	0x95727cb1 -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] + 759
10  com.apple.AppKit              	0x957275f3 -[NSThemeFrame _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] + 306
11  com.apple.AppKit              	0x95724117 -[NSView _displayRectIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:] + 3090
12  com.apple.AppKit              	0x95664b77 -[NSView displayIfNeeded] + 933
13  com.apple.AppKit              	0x95664725 -[NSWindow displayIfNeeded] + 189
14  com.apple.AppKit              	0x9572026f -[NSWindow _reallyDoOrderWindow:relativeTo:findKey:forCounter:force:isModal:] + 1354
15  com.apple.AppKit              	0x9571fcc8 -[NSWindow orderWindow:relativeTo:] + 105
16  com.apple.AppKit              	0x956e765a -[NSWindow makeKeyAndOrderFront:] + 189
17  com.heat.dockless             	0x0000360c -[DOController applicationDidFinishLaunching:] + 3228

[Chuckit]

I notice that it's trying to access memory at UINT_MAX. Could it be that one of your "Intel laptops" uses a Core Duo (32-bit) and the other uses a Core 2 Duo (64-bit), so there's an overflow condition hidden somewhere?

[Ghoser777]

Wow... I'll check. I can't imagine where that would be happening...

[Ghoser777]

Hmm... my specs are the following:

2.16 GHz Intel Core 2 Duo (that would be a 64 bit processor, yes?)

His specs:

MacBook Pro 2.16 Ghz (I think it's a Core 2 Duo... which would mean it's 64 bit as well... right?)

My project settings are targeting a Standard 32 bit Universal Binary (I can't target 64 as I'm using Carbon).

[Ghoser777]

ChuckIt - could you enlighten me and explain how you knew it was accessing the UINT_MAX constant?

[Chuckit]

I must not have phrased that quite right. I don't think it is accessing the constant specifically. But if you look at the crashlog, it says it's crashing because you're trying to access a bad address at 0xffffffff. That's the maximum value that an integer (or a pointer) can hold in a 32-bit address space. There's no reason code would ever intentionally try to dereference that location. That's why it looks like an overflow to me. Although now that I think about it, I guess it's more like an underflow (like if somebody tried to access NULL-1). Is it possible that you're passing on the result of a function that succeeds on your system but returns NULL/nil on his?

Sorry I don't have anything more specific, but that's my best guess from the error you're getting: Somebody's trying to decrement NULL.

And yeah, if you're both using Core 2 Duo and building for 32-bit, it can't be a matter of address space size.

[Ghoser777]

OH! Yeah, now that makes sense. I have no idea where anything I do would cause that, but now I have something to look for. Thanks.

[Ghoser777]

Okay, I fixed the problem... although I'm not sure I totally understand why it happened. Let me know if I'm off base here:

Any message you send to nil has no effect. Example:

NSObject *ex = nil;
[ex doSomething];

What I thought I was doing was:

[ex autorelease];

So I thought it would not be a problem (let me know if that's not the case). What I had happening instead was something like this:

NSObject *ex = NULL;
[ex autorelease];

And that was causing my problem. Simple fix of course was doing a quick check case.

I got very good about watching my reference counting in Objective-C, but I ran into this bug after making a Carbon call to an allocator function that could return NULL.

[Chuckit]

I don't suppose you might have enabled the -fno-nil-receivers/"Assume non-nil receivers" build option, by any chance?

[Ghoser777]

Extremely doubtful (considering I didn't know that it existed).