Re: Haywired Call Stack in resymbolized Crash Report
Re: Haywired Call Stack in resymbolized Crash Report
- Subject: Re: Haywired Call Stack in resymbolized Crash Report
- From: Jerry Krinock <email@hidden>
- Date: Thu, 19 Nov 2009 08:14:44 -0800
On 2009 Nov 18, at 08:07, Jeff Johnson wrote:
> 1) Architecture mismatch. You didn't mention which architecture your Mac has. Also, was the user running 64-bit (x86-64) or 32-bit (i386)? If there is architecture mismatch, then gdb may not work. I tend to use 'dwarfdump --arch= --lookup=' rather than gdb to symbolize crash reports.
Thanks, Jeff. That wasn't the problem this time but I've noted that for future reference.
> 3) Mismatch of framework load address. Your framework is almost certainly loading at a different address of the user's machine than on your machine (randomization). Therefore, you must take into account the load address of the framework in the crash report when symbolizing.
>
> http://developer.apple.com/mac/library/technotes/tn2004/tn2123.html
Indeed, that was the problem. After calculating and adding in the "slide", I get answers that are more self-consistent.
By the way, it seems that Crash Reporter now calculates the slide for you. For example, in this line:
1 com.sheepsystems.Bkmxwork 0x000c5c49 0x7000 + 781385
After going through the procedure of calculating the slide using otool as explained in TN2123, it turned out to be 0x7000. Does anyone know if this is a new feature of Crash Reporter that is not yet documented in TN2123?
_______________________________________________
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