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: Tue, 25 Mar 2008 17:59:49 -0700
An off-list respondent suggested that possibly Panther is not
correctly initializing the NSString category in my framework into the
NSString class. I added a +initialize method to my category, and got
a strange result which might give someone a clue...
@implementation NSString (Crash)
+ (void)initialize {
NSLog(@"Class: %@ initializing. self: %p",
NSStringFromClass(self), self);
}
... // My other method which crashes when it sends an internal
message, as in
... // http://www.cocoabuilder.com/archive/message/cocoa/2008/3/21/201996
@end
Now, please understand that I'm not sure whether or not it's kosher to
add +initialize in a category on a Cocoa class, but the interesting
thing is that when I run this in Leopard, seven classes (it's a
"cluster", I suppose) are initialized without complaint...
TestApp[88066:10b] Class: NSCFString initializing. self: 0xa00a14a0
TestApp[88066:10b] Class: NSMutableString initializing. self:
0xa03f7480
TestApp[88066:10b] Class: NSPlaceholderString initializing. self:
0xa03f8f40
TestApp[88066:10b] Class: NSString initializing. self: 0xa03f8f00
TestApp[88066:10b] Class: NSCheapMutableString initializing.
self: 0xa03f74c0
TestApp[88066:10b] Class: NSPathStore2 initializing. self:
0xa03f7ac0
TestApp[88066:10b] Class: NSPlaceholderMutableString
initializing. self: 0xa03f7500
When I run this in Panther, ten classes are initialized (looks like
Apple has trimmed some of the fat since then), but in the first four
of them, +initialize seems to run before there is an autorelease pool...
TestApp[4105] *** _NSAutoreleaseNoPool(): Object 0x301270 of class
NSCFString autoreleased with no pool in place - just leaking
TestApp[4105] Class: NSCFString initializing. self: 0xa01c05f4
TestApp[4105] *** _NSAutoreleaseNoPool(): Object 0x309600 of class
NSCFString autoreleased with no pool in place - just leaking
TestApp[4105] Class: %NSCFString initializing. self: 0xa0a35c9c
TestApp[4105] *** _NSAutoreleaseNoPool(): Object 0x301100 of class
NSCFString autoreleased with no pool in place - just leaking
TestApp[4105] Class: NSMutableString initializing. self: 0xa0a35fcc
TestApp[4105] *** _NSAutoreleaseNoPool(): Object 0x307010 of class
NSCFString autoreleased with no pool in place - just leaking
TestApp[4105] Class: NSString initializing. self: 0xa0a360ec
TestApp[4105] Class: NSCheapMutableString initializing. self:
0xa0a35f9c
TestApp[4105] Class: NSPathStore2 initializing. self: 0xa0a356cc
TestApp[4105] Class: NSPlaceholderString initializing. self:
0xa0a360bc
TestApp[4105] Class: NSPlaceholderMutableString initializing.
self: 0xa0a35f6c
TestApp[4105] Class: NSBigMutableString initializing. self:
0xa0a35c6c
TestApp[4105] Class: NSBulletString initializing. self: 0xa72188d0
Now, it sort of makes sense. The first four classes to be
+initialized are NSCFString, %NSCFString, NSMutableString and
NSString. If indeed it is not kosher to add a +initialize method in a
category, then I suppose it is possible that the autorelease pool
might not be in place for an NSString before NSString is initialized.
(I realize the previous sentence is 50% nonsense, but I'm groping in
the dark!) But why the difference in Panther? Maybe it's the same
thing causing my other methods to crash.
Anyhow, if this gives anyone a clue as to why a simple method in a
category on NSString in a private framework would crash the first time
it sends an internal message, please let us know. In case you missed
this thread last week, want to see the details and/or download build
transcripts and/or a demo project, here's a handy link...
http://www.cocoabuilder.com/archive/message/cocoa/2008/3/21/201996
Jerry Krinock
_______________________________________________
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