Re: Cocoa called from Carbon, objc_msgSend crash in 10.3.9.
Re: Cocoa called from Carbon, objc_msgSend crash in 10.3.9.
- Subject: Re: Cocoa called from Carbon, objc_msgSend crash in 10.3.9.
- From: John Stiles <email@hidden>
- Date: Mon, 18 Dec 2006 17:42:02 -0800
Unless your app is doing very clever things, there isn't any
justification for allocating an autorelease pool without releasing it.
These are particularly tricky because they are implemented in a
stack, and if you do not keep the stack properly balanced, it is
quite easy to make crash-inducing mistakes.
On Dec 18, 2006, at 5:37 PM, Matt Fox-Wilson wrote:
Thanks for the ideas there. Some more info:
The gCString class does implement a uint16* operator. I'm not
entirely sure why we don't have a UniChar operator but I didn't
handle that side of things.
I checked to see if we were calling NSApplicationLoad and it
appears we weren't, so I've added a call to that in our .mm file
and I'm now calling it from main() to see if that helps.
Originally, we didn't include the [pool release]; because,
apparently, the person who wrote the Cocoa call functions found
some notes indicating that it shouldn't be called. I can't confirm
the location of those, and I'm willing to try anything so we'll
give it a shot. I'll build with those and the NSApplicationLoad
call and see if our user reports a fix.
Thanks for the rapid suggestions!
- Matt Fox-Wilson
- email@hidden
From: John Stiles [mailto:email@hidden]
Sent: Tuesday, 19 December 2006 11:58 a.m.
To: David Duncan
Cc: Matt Fox-Wilson; email@hidden
Subject: Re: Cocoa called from Carbon, objc_msgSend crash in 10.3.9.
Even if there is a vtable, I suspect that this would technically
work because the vtable shows up at (Byte*)this - sizeof(void*).
I agree that it is skanky, though... unless his class implements an
operator uint16*, in which case it is fine. If the class doesn't
already include this operator, it should be added right away for
safety.
On Dec 18, 2006, at 2:52 PM, David Duncan wrote:
On Dec 18, 2006, at 2:28 PM, Matt Fox-Wilson wrote:
gCString sResult = L"";
UniChar* sSource = (UniChar*)(uint16*)sRef;
This may not actually be a problem, but it is relying on the
internal layout of your class to function properly (I'm assuming
sRef is another instance of a gCString?). Unless the UniChar
buffer is inline at the start of this class and there are no
virtual functions, this shouldn't work. All of that may even be
true, but I wouldn't rely on it and it would probably be very
useful to add a UniCharPtr() accessor to your class that just
returns a UniChar* to your characters.
if (sRef.Length() < 1) return sResult;
NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
NSString * nsSrc = [NSString stringWithCharacters:sSource
length:sRef.Length()];
NSString* nsExt = [nsSrc lastPathComponent];
sResult.CopyString((CFStringRef)nsExt);
return sResult;
--
David Duncan
Apple DTS Quartz and Printing
email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
40blizzard.com
This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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