• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Mysterious crash in objc_msgSend in GC app
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • Follow-Ups:
    • Re: Mysterious crash in objc_msgSend in GC app
      • From: "Sean McBride" <email@hidden>
References: 
 >Mysterious crash in objc_msgSend in GC app (From: "Sean McBride" <email@hidden>)
 >Re: Mysterious crash in objc_msgSend in GC app (From: Greg Parker <email@hidden>)
 >Re: Mysterious crash in objc_msgSend in GC app (From: "Sean McBride" <email@hidden>)

  • Prev by Date: Re: Mysterious crash in objc_msgSend in GC app
  • Next by Date: Re: waiting for async callback in main thread
  • Previous by thread: Re: Mysterious crash in objc_msgSend in GC app
  • Next by thread: Re: Mysterious crash in objc_msgSend in GC app
  • Index(es):
    • Date
    • Thread