• 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: Sudden and hard to reproduce crashes in libcache
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Sudden and hard to reproduce crashes in libcache


  • Subject: Re: Sudden and hard to reproduce crashes in libcache
  • From: Fritz Anderson <email@hidden>
  • Date: Thu, 23 Feb 2012 10:20:03 -0600

On 21 Feb 2012, at 8:50 AM, Dragan Milić wrote:

> 7   libc++abi.dylib               	0x00007fff8a1e505c std::terminate() + 16
> 8   libc++abi.dylib               	0x00007fff8a1e6152 __cxa_throw + 114
> 9   libobjc.A.dylib               	0x00007fff8a699e7a objc_exception_throw + 327
> 10  com.apple.CoreFoundation      	0x00007fff8c8b92a9 -[NSException raise] + 9
> 11  com.apple.ExceptionHandling   	0x0000000100332e0a NSExceptionHandlerUncaughtSignalHandler + 37
> 12  libsystem_c.dylib             	0x00007fff900f0cfa _sigtramp + 26
> 13  com.apple.CoreFoundation      	0x00007fff8c793c0b CFRelease + 27

The stack trace shows an uncaught NSException. Do you have the log from the time of the crash? Even if you can't reproduce it yourself, you can have a user look in Console, all messages, search for your application ID, and send you the results.

> I see the crash happens after CFRelease() call, but I can't figure out why. If I try to do CFRelease(NULL), I get almost the same sequence…


Are you using ARC, by chance? Are any of the objects held as weak? Are you transferring them to Core Foundation without the proper bridging attribute?

If you can reproduce it yourself, here are some (possibly superstitious) things you could do:

Use the Breakpoint inspector (the [+] button) to set a breakpoint on exceptions. This may or may not tell you something. Assuming you are running on Intel, have a look at Tech Note 2124, "Mac OS X Debugging Magic," to decode parameters from assembly (the section is "Some Assembly Required). <https://developer.apple.com/library/mac/#technotes/tn2124/_index.html>

Enable zombies. Again, probably superstitious (unless the memory of the cached object was filled with a different one). Product > Edit Scheme…; Run > Diagnostics > Enable Zombie Objects.

If you know the class of the expected object, use the Object Alloc instrument to collect allocation history (optionally with zombie detection) and see if there are excessive releases. You will have to do a throwaway run at first, and set the instrument's options to collect history and zombies.

	— F


_______________________________________________

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


References: 
 >Sudden and hard to reproduce crashes in libcache (From: Dragan Milić <email@hidden>)

  • Prev by Date: Re: Determining user's clock preference on iOS
  • Next by Date: Loading existing NIB file from Cocoa?
  • Previous by thread: Sudden and hard to reproduce crashes in libcache
  • Next by thread: Re: Sudden and hard to reproduce crashes in libcache
  • Index(es):
    • Date
    • Thread