Re: Mysterious crash in objc_msgSend in GC app
Re: Mysterious crash in objc_msgSend in GC app
- Subject: Re: Mysterious crash in objc_msgSend in GC app
- From: Greg Parker <email@hidden>
- Date: Tue, 27 Oct 2009 13:57:31 -0700
On Oct 27, 2009, at 1:24 PM, Sean McBride wrote:
On 10/27/09 11:30 AM, Greg Parker said:
I'm able to determine that the selector was from libobjc.A.dylib
but I
don't know which (the uuid from dwarfdump does not match mine).
The selector is `_handleRecognitionDoneWithRecognitionResult:`, which
How did you determine that? Like the report submitter, I have 9L30,
but
I get:
dwarfdump -u /Volumes/Leopard/usr/lib/libobjc.A.dylib
UUID: A1D4BE2E-ED46-3C67-99B6-A1447FDE72BA (ppc7400) /Volumes/Leopard/
usr/lib/libobjc.A.dylib
UUID: 0767EFCB-41C0-AAFB-B4B1-22CDEC825DCE (ppc64) /Volumes/Leopard/
usr/
lib/libobjc.A.dylib
UUID: 3CA288B6-25A4-7BBC-FE37-8158E4DC328F (i386) /Volumes/Leopard/
usr/
lib/libobjc.A.dylib
UUID: EFC7EBDF-E5EA-8B72-3EBD-B322CE775DDF (x86_64) /Volumes/Leopard/
usr/
lib/libobjc.A.dylib
Where is the ae894159f17cfb7673373132cab14f77 one from?
10.5.7, at least. libobjc was recompiled but otherwise unchanged
during one of those updates. I'd guess that you could end up with one
version or the other depending on your path through the software
update chain, variables like patch updaters, combo updaters, and
upgrades on boxed DVDs or new hardware.
The UUID is the most trustworthy way to identify a binary - that's
what it's there for. The OS version is useful, but not always as
immutable as you might like.
is from NSSpeechRecognizer. It looks like NSSpeechRecognizer fixed a
GC bug in Snow Leopard;
Interesting. I was not aware of any NSSpeechRecognizer bug. I know
about NSSpeechSynthesizer having a bug with GC <rdar://6073042>
which I
have already worked around.
Could you tell me a bit more about the bug? Currently, I store my
NSSpeechRecognizer in an ivar, process spoken commands, the send it -
stopListening, then nil my ivar.
NSSpeechRecognizer passes `self` to a void* callback context
parameter. Under GC it should use CFRetain() to keep itself alive
until the callback returns, but on Leopard it still used [self
retain]. You get the crash when GC throws the object away and then the
callback fires again.
Assuming my diagnosis is correct, I'd recommend using CFRetain() to
keep each NSSpeechRecognizer alive forever, and recycle them with
setCommands:/startListening/stopListening. Alternatively just CFRetain
() and leak them, if they're hard to recycle and you don't allocate
very many.
--
Greg Parker email@hidden Runtime Wrangler
_______________________________________________
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