Re: garbage collection is ON NSCFDictionary crash
Re: garbage collection is ON NSCFDictionary crash
- Subject: Re: garbage collection is ON NSCFDictionary crash
- From: Bill Bumgarner <email@hidden>
- Date: Tue, 03 Feb 2009 09:23:32 -0800
(Cc'ing the list w/the OP's permission)
On Feb 3, 2009, at 8:25 AM, Jesse Grosjean wrote:
If you can reproduce the crash at all, run your app with
MallocStackLoggingNoCompact set and then use malloc_history to find
out who
allocated the object.
However....
Does the crash always include:
Exception Codes: KERN_INVALID_ADDRESS at 0x00000000a1b1c1d8
That seems like a rather suspicious address. a1b1c1d8? Fishy.
It doesn't always include that address, but the addresses aren't
random. Here's a selection:
Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000005
Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000005
Exception Codes: KERN_INVALID_ADDRESS at 0x00000000a1b1c1d8
Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000005
Exception Codes: KERN_INVALID_ADDRESS at 0x000000001ecfad81
Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000005
Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000005
Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000005
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000065746e6e
So 0x0000000000000005 is showing up a lot, but not always.
It looks most likely like a non-pointer value is being dropped into a
slot where a pointer is expected. I.e. somebody done corrupted your
heap!
Or, if not corruption, there is something somewhere that is storing
raw data into slots that expect references to objects (including
CFTypes and random chunks of malloc()ed data -- "object" in the "chunk
of heap" sense, not "NSObject subclass" sense).
If you can figure out a reproducible case (see below for some ideas),
then running with guard malloc may prove useful.
In the console logs that people send me lots of people have input
managers with GC capability mismatch's. For example:
log: 2009-02-03 04:58:58 -0800[3]: Error loading
/Library/InputManagers/GearsEnabler/GearsEnabler.bundle/Contents/
MacOS/GearsEnabler:
dlopen(/Library/InputManagers/GearsEnabler/GearsEnabler.bundle/
Contents/MacOS/GearsEnabler,
265): no suitable image found. Did find:
/Library/InputManagers/GearsEnabler/GearsEnabler.bundle/
Contents/MacOS/GearsEnabler:
GC capability mismatch
But I'm assuming that in those cases things fail really early, and the
code just isn't loaded. So I doubt they could be the cause right?
Shouldn't be. But it does mean that your users are using unsupported
extensions to the OS that may be causing issues.
For example, GearsEnabler is most likely this:
http://osx.iusethis.com/app/gearsenabler
In any case, since it isn't compiled with GC support enabled, it won't
mess up your particular application.
But it does raise the question of what other "extensions" your users
might be using and how they might break things.
Are you creating any CFDictionaries that have any of the atypical
storage patterns?
I'll look around, I wouldn't put it past me... but at the moment I
can't see anything odd that I'm doing. I do keep static references to
some dictionaries like this, but that's OK under GC right?
+ (NSDictionary *)dashSpaceAttributes {
static NSMutableDictionary *dashSpaceAttributes = nil;
if (!dashSpaceAttributes) {
dashSpaceAttributes = [NSMutableDictionary dictionary];
[dashSpaceAttributes setObject:[NSFont userFontOfSize:0]
forKey:NSFontAttributeName];
[dashSpaceAttributes setObject:[NSNumber numberWithFloat:1]
forKey:NSExpansionAttributeName];
}
return dashSpaceAttributes;
}
No, that is fine.
The question was more directed at whether or not you are creating
CFDictionaries directly, possibly passing in custom callbacks that
allow for non-object stuff to be shoved into 'em. This can be quite
fragile if not done with extreme care.
The one thing common with most (not all) of the crash reports is that
my app seemed to be running in the background, and then it just
crashes. Here are some reports:
So in most crashes thread 0 just looks like this:
Thread 0:
0 libSystem.B.dylib 0x94617438 mach_msg_trap 8
1 libSystem.B.dylib 0x9461e35c mach_msg 56
2 com.apple.CoreFoundation 0x92559568
CFRunLoopRunSpecific 1812
3 com.apple.HIToolbox 0x93e79d44
RunCurrentEventLoopInMode 264
4 com.apple.HIToolbox 0x93e79b68
ReceiveNextEventCommon 412
5 com.apple.HIToolbox 0x93e799a8
BlockUntilNextEventMatchingListInMode 84
6 com.apple.AppKit 0x93147e18 _DPSNextEvent 596
7 com.apple.AppKit 0x931477d0 -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] 112
8 com.apple.AppKit 0x9314148c -[NSApplication
run] 736
9 com.apple.AppKit 0x93111e90
NSApplicationMain 440
10 TaskPaper 0x00001e0c start 64
Right -- your app is waiting for an event when it crashes.
So... it must be triggered by something else.
Do you have a software update mechanism that checks every now and then?
Ahh... it appears that you do. Sparkle. Cool -- but -- it
periodically checks for updates? Can you put a local copy of your
app in a mode where it checks often and see what happens?
Anything listening for distributed notifications or the like?
Any kqueues or other system resource monitors that might wake up?
b.bum
_______________________________________________
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