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: "Matt Fox-Wilson" <email@hidden>
- Date: Tue, 19 Dec 2006 16:52:13 +1300
I just got a reply from the user and apparently he still has the crash after
I added the NSApplicationLoad and the pool releases. The crash log indicates
the same thing as before:
Exception: EXC_BAD_ACCESS (0x0001)
Codes: KERN_INVALID_ADDRESS (0x0001) at 0x4e534195
Thread 0 Crashed:
0 libobjc.A.dylib 0x908611ec objc_msgSend + 0xc
1 com.AmbientDesign.ArtRage2 0x0018929c 0x1000 + 0x18829c
2 com.AmbientDesign.ArtRage2 0x0010e564 0x1000 + 0x10d564
3 com.AmbientDesign.ArtRage2 0x000cf508 0x1000 + 0xce508
4 com.AmbientDesign.ArtRage2 0x00138794 0x1000 + 0x137794
5 com.AmbientDesign.ArtRage2 0x0002af5c 0x1000 + 0x29f5c
6 com.AmbientDesign.ArtRage2 0x002da3a8 0x1000 + 0x2d93a8
7 dyld 0x8fe17754
call_module_initializers_for_objects + 0x1ac
8 dyld 0x8fe1721c call_module_initializers +
0x40
9 dyld 0x8fe14348
_dyld_make_delayed_module_initializer_calls + 0x6c
10 com.AmbientDesign.ArtRage2 0x00008754 0x1000 + 0x7754
11 com.AmbientDesign.ArtRage2 0x00008548 0x1000 + 0x7548
12 com.AmbientDesign.ArtRage2 0x000084a8 0x1000 + 0x74a8
One thing I forgot to add in my previous notes was that the function that is
causing this crash is also used in another of our apps and that is running
fine for him. The apps are pretty different, but their startup procedure is
the same: In Main, the app tries to locate an external resource file we
provide for its UI, and in doing so calls the function I outlined before to
get a path.
Thanks for all the ideas, I've been going through and making sure that the
releases are all stacked properly!
- Matt Fox-Wilson
- email@hidden
_____
From: John Stiles [mailto:email@hidden]
Sent: Tuesday, 19 December 2006 2:42 p.m.
To: Matt Fox-Wilson
Cc: 'David Duncan'; email@hidden
Subject: Re: Cocoa called from Carbon, objc_msgSend crash in 10.3.9.
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:
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