• 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: Interpreting Call Stack when Crash occurs in Inline Function
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Interpreting Call Stack when Crash occurs in Inline Function


  • Subject: Re: Interpreting Call Stack when Crash occurs in Inline Function
  • From: Ken Thomases <email@hidden>
  • Date: Mon, 26 Dec 2011 18:14:19 -0600

On Dec 26, 2011, at 4:31 PM, Jerry Krinock wrote:

> If you declare a C function as inline, and this function invokes other functions, does this function appear to invoke itself in the call stack of a crash report?
>
> See lines 5-8, in this call stack.  'MyFunction' is declared 'inline' and does not call itself.
>
> Application Specific Information:
> *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '*** -[NSCFDictionary setObject:forKey:]: attempt to insert nil key'
> *** Call stack at first throw:
> (
>     0   CoreFoundation   0x949176ca __raiseError + 410
>     1   libobjc.A.dylib  0x96f5a5a9 objc_exception_throw + 56
>     2   CoreFoundation   0x949173f8 +[NSException raise:format:arguments:] + 136
>     3   CoreFoundation   0x9491736a +[NSException raise:format:] + 58
>     4   Foundation       0x9886b39f -[NSCFDictionary setObject:forKey:] + 185
>     5   MyFramework      0x0014122d MyFunction + 462947
>     6   MyFramework      0x001415fd MyFunction + 463923
>     7   MyFramework      0x00082f01 0x0 + 536321
>     8   MyFramework      0x000e9257 MyFunction + 102541
>     9   Foundation       0x98894671 __NSThreadPerformPerform + 506
>     10  CoreFoundation   0x9488242b __CFRunLoopDoSources0 + 1563
>     11  CoreFoundation   0x9487feef __CFRunLoopRun + 1071
>     12  CoreFoundation   0x9487f3c4 CFRunLoopRunSpecific + 452
>     13  CoreFoundation   0x9487f1f1 CFRunLoopRunInMode + 97
>     14  Foundation       0x988b81b3 -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 279
>     15  My-Helper        0x000039d6 0x0 + 14806
>     16  My-Helper        0x00001bd5 0x0 + 7125
>     17  ???              0x00000005 0x0 + 5
>
> If so, then I interpret the above to say that the NSDictionary exception is being raised by a function two levels higher in the call stack than MyFunction.  Or is it three?  I'm not sure what to make of the "0x0 + 536321".

I don't think this has anything to do with MyFunction, inlined or not.  The offsets are huge, much larger than a typical function.

Basically, your framework has had its symbols stripped, as is fairly common.  So, when the crash reporter goes to correlate an instruction address to a symbol, it finds some unrelated symbol -- basically the closest prior symbol that's still in the binary.  In the case of "0x0 + 536321", there wasn't even that much, so it's just an offset from the start of the image.

You'll need to symbolicate this.  See here <https://developer.apple.com/library/mac/technotes/tn2004/tn2123.html#SECNOSYMBOLS>.

Good luck.

Regards,
Ken

_______________________________________________

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: Crash Reporter lies. Was: Interpreting Call Stack…
      • From: Jerry Krinock <email@hidden>
References: 
 >Interpreting Call Stack when Crash occurs in Inline Function (From: Jerry Krinock <email@hidden>)

  • Prev by Date: Interpreting Call Stack when Crash occurs in Inline Function
  • Next by Date: what is at table's "index row limit" in the nib editor?
  • Previous by thread: Interpreting Call Stack when Crash occurs in Inline Function
  • Next by thread: Re: Crash Reporter lies. Was: Interpreting Call Stack…
  • Index(es):
    • Date
    • Thread