Re: Reading crash reports
Re: Reading crash reports
- Subject: Re: Reading crash reports
- From: Paul Lynch <email@hidden>
- Date: Tue, 18 Apr 2006 12:55:00 +0100
On 18 Apr 2006, at 12:36, Pierre Bernard wrote:
I am having trouble making sense of crash reports.
E.g.:
Thread 0 Crashed:
0 libobjc.A.dylib 0x90a3e100 objc_msgSend + 32
1 HoudahSpot 0x0001466c -[ResultController
queryNotification:] + 396 (crt.c:355)
2 com.apple.Foundation 0x92931ad8 _nsnote_callback + 180
3 com.apple.CoreFoundation 0x908034c4 __CFXNotificationPost + 368
4 com.apple.CoreFoundation 0x907fb5a0
_CFXNotificationPostNotification + 684
5 com.apple.Foundation 0x9291bee0 -[NSNotificationCenter
postNotificationName:object:userInfo:] + 92
I have read the Apple technote on the subject. All seems easy.
The catch is that Apple's examples has line numbers. In the real
backtraces I am seeing I have seemingly random numbers in the same
place.
-[ResultController queryNotification:] is around line 100 in the
source. I have no idea what "+ 396 (crt.c:355)" refers to.
These aren't random numbers; they are offsets within the executable
code, calculated from your method start points. These are calculated
from the symbol tables that are left in a stripped executable.
If you want to have line numbers in your code, as the Apple example
(rather naively) shows, then you need to build and ship your
application unstripped, with a symbol table containing debugging
symbols. This makes your code rather easy to reverse engineer, but
helps with debugging, which is almost the same task.
A standard project will have both a Debug and a Deployment build
configuration; the names will vary according to which version of
Xcode was used to create the original project.
Paul
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden