Re: Simple Out-of-Box Demo: Private Framework Crashes in 10.3.9
Re: Simple Out-of-Box Demo: Private Framework Crashes in 10.3.9
- Subject: Re: Simple Out-of-Box Demo: Private Framework Crashes in 10.3.9
- From: Jerry Krinock <email@hidden>
- Date: Wed, 26 Mar 2008 16:45:44 -0700
I found a workaround. First, I'll answer Greg's questions....
On 2008 Mar, 25, at 22:39, Greg Parker wrote:
Don't add +initialize in a category. The category's method will
replace any present in the original class, which could break that
class.
Agreed. As I said, I just wanted to "apply pressure" to see if
anything interesting popped up.
What happens if you compile your code with -fno-constant-cfstrings?
Setting, in "Other C Flags", -fno-constant-cfstrings, recompiling and
running in 10.3.9,
Setting this flag in the main app only , no effect. Still crashes
upon executing -[NSDictionary setObject:forKey].
Setting this flag in both the main app and the framework, it makes
things worse. Now it crashes immediately upon sending the
+crashMe to the framework, or possibly at NSLog(@"checkpoint 1").
It never even gets to -[NSDictionary setObject:forKey].
What happens if you copy the contents +crashMe into -
applicationDidFinishLaunching: , and omit the call to +crashMe
completely?
This executes OK with no crash.
What happens if you do the above, and also delete your NSString
category?
Did not try this test because it is obviated by the previous test
result.
What happens if you call `[@"name" copyWithZone:NULL]` directly,
from either +crashMe or -applicationDidFinishLaunching:
I de-activated -fno-constant-cfstrings so the framework would execute
again.
Results:
In the main app, in -applicationDidFinishLaunching, no crash.
In the framework, in +crashMe, [@"name" copyWithZone:NULL] causes
a crash.
*************
Now, the workaround...
(1) Add the following class to my framework:
@implementation PantherFixer
+ (void)fix { }
@end
(2) In the main app, first line in -applicationDidFinishLaunching, add
[PantherFixer fix] ;
Result: Subsequently invoking +crashMe no longer causes a crash.
Applying these two steps to my real app fixes the problem in my real
app too.
My hypothesis is: A bug in Mac OS 10.3 which causes a crash when
frameworked code in a Cocoa category executes before any "regular"
code in that framework executes. It's as though the framework is
lazily wired up to Cocoa when needed, but if the need is from a
category method, it gets wired wrong, particularly to NSString.
Indeed the above trigger would be a rather rare occurrence in the
world, so not many people noticed. Either it was one of the thousands
of unspecified bugs fixed in Tiger, or it got fixed by accident when
the "class cluster" magic got reworked for Tiger.
Thanks again to Greg and everyone who read this.
_______________________________________________
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