• 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
Haywired Call Stack in resymbolized Crash Report
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Haywired Call Stack in resymbolized Crash Report


  • Subject: Haywired Call Stack in resymbolized Crash Report
  • From: Jerry Krinock <email@hidden>
  • Date: Mon, 16 Nov 2009 10:23:12 -0800

I received a crash report from a user. The call stack for crashed thread 0 contained 3 lines in a stripped private framework, which I symbolized using gdb. I did this by moving the relevant app version to a folder containing the dSYM files for the relevant version, launching gdb, commanding 'set sharedlibrary preload-libraries no', and then opening the appropriate binary in Contents/Frameworks/.... The crash report specifies x86 architecture and Mac OS 10.6.2. My Mac is running 10.5.

The line numbers given by gdb 'info line' command do occur within the given method name. However, I expect that the code given in line N of the call stack should invoke the function/method given in line N-1 of the call stack. But they do not.

I was wondering if anyone had ever seen gdb give a haywired call stack like this and, if not, what else might I have done wrong?

Here is part of the call stack, with the symbol results from gdb 'info line' pasted in:

0 libobjc.A.dylib 0x96ddeedb objc_msgSend + 27
1 com.sheepsystems.Bkmxwork 0x000c5c49 0x7000 + 781385 Line 305 of Bkmslf+ActionValidator.m starts at address 0xc5c45 <- [Bkmslf(ActionValidator) validateMenuItem:]+2140> and ends at 0xc5c4d <-[Bkmslf(ActionValidator) validateMenuItem:]+2148>.
2 com.sheepsystems.Bkmxwork 0x000c7893 0x7000 + 788627 Line 205 of StarkPredicateEditor.m starts at address 0xc7875 <- [StarkPredicateEditor addSimpleRowPresetToAttributeKey:operatorType:asSubrowOfRow:targetValue :]+582> and ends at 0xc78ba <-[StarkPredicateEditor addSimpleRowPresetToAttributeKey:operatorType:asSubrowOfRow:targetValue :]+651>.
3 com.sheepsystems.Bkmxwork 0x000d4054 0x7000 + 839764 Line 1730 of Bkmslf.m starts at address 0xd401e <-[Bkmslf availableClientChoices]+351> and ends at 0xd4056 <-[Bkmslf availableClientChoices]+407>.
4 com.apple.AppKit 0x94d170ae -[NSView rightMouseDown:] + 68


As an example of the haywiring, look at line 3 of the call stack. I expect that line 1730 of Bkmslf.m should be invoking the method referenced in line 2, -[StarkPredicateEditor addSimpleRowPresetToAttributeKey:operatorType:asSubrowOfRow:targetValue :]. But here is the actual code:

1728: NSMutableArray* clientChoices = [[NSMutableArray alloc] init] ;
1729: for (Client* client in clients) {
1730: [clientChoices addObject:[ClientChoice clientChoiceWithClient:client]] ;
1731: }


As you can see, it's not even close.

Big thanks to anyone who could offer a guess as to what might have gone wrong.

Jerry Krinock

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Follow-Ups:
    • Re: Haywired Call Stack in resymbolized Crash Report
      • From: Jeff Johnson <email@hidden>
  • Prev by Date: Re: Stupid "warning: declaration of 'index' shadows a global declaration"
  • Next by Date: Prevent gdb from stays running when executable exits with non-zero result?
  • Previous by thread: Re: Console log swamped by malloc free_garbage warnings
  • Next by thread: Re: Haywired Call Stack in resymbolized Crash Report
  • Index(es):
    • Date
    • Thread