Re: Using atos & reading crash logs
Re: Using atos & reading crash logs
- Subject: Re: Using atos & reading crash logs
- From: Rick Altherr <email@hidden>
- Date: Wed, 11 Feb 2009 21:32:24 -0800
On Feb 11, 2009, at 2:38 PM, Eric Gorr wrote:
I was playing around with atos a bit after having read:
http://developer.apple.com/tools/xcode/symbolizingcrashdumps.html
In this document, it says:
"If enough debugging information is available,
the tool also supplies the source file name
and line number for the address."
The fact that I may be able to get a line number based upon passing
it an address from a crash report intrigues me.
I wrote some code which deliberately caused a crash in the debug
version of my application and in the crash report I saw:
0x008ed9f8 PromptToSaveFile(unsigned char const*, bool) + 90
so, I run atos by doing:
atos -o /Path/to/myapp.app/Contents/MacOS/myapp 0x008ed9f8
but, only got back:
PromptToSaveFile(unsigned char const*, bool) (in myapp) + 90
which is nothing more then what the crash log told me. I was hoping
it might give me back a line number, but apparently enough debugging
information wasn't available.
Is there a way to make enough debugging information available?
The simple answer is the program needs to be built with -g and not
stripped. In terms of an Xcode project, you want to turn "Generate
Debugging Information" on and change the strip level to "None". If
you use DWARF w/ dSYM as a debug format, the stripping setting won't
matter. Just make sure the .dSYM is next to the original binary when
running atos. Also be sure to use XCode 3.1 or later when using atos
w/ dSYMs. There were a few known bugs in 3.0.
*****
The reason I am playing around with this is that my real case is far
more difficult to manage. I have a crash log from the release
version of the application, which, of course, has all of the various
optimizations turned on. While I do have crash log which mentions
information like:
0x008ed9f8 PromptToSaveFile(unsigned char const*, bool) + 90
I don't have an easy way to determine exactly where in the function
it crashed as the function is rather big and contains a massive
switch statement which is based on parameters which are passed into
the function. I am fairly certain the crash is occurring in one of
the case statements, but I am uncertain how to determine which one
it is.
Unfortunately, I don't have much experience reading crash logs. So,
any advice on this topic would be appreciated.
If you build your release version with a dSYM, then you can use the
list of loaded binaries along with atos and the dSYM to get the line
it crashed on. In the crash log, look at the crashed thread and write
down the address of the function that crashed. Then, scroll down to
the list of binaries. Find the binary that contained the address of
the function that crashed. Note the start address of the range for
that binary. Put the .dSYM next to the app bundle (or framework,
binary, etc) and then run atos on the binary providing the start
address as the slide value (you may need to adjust the start address
depending on if you use prebinding or not and if the first address is
your binary is 0x0 or not). Then feed atos the address that crashed
and it will tell you the function, file, and line that corresponds to
that address.
*****
btw, the code I wrote to deliberately cause the crash looks like:
char *a = NULL;
char *b = (char*)20;
strcpy( a, "hello" );
strcpy( a, b );
a[10] = docName[4];
CFShow( NULL );
There is clearly more then is necessary, but the reason for that is
I was trying to get the optimized build of my application to crash
as well. Apparently, the optimizer is to smart for me and it won't
crash...I'm guessing because it knows that all of this code is
irrelevant and just optimizes it away. Strange how hard it is to get
a crash to occur when you want it to, but how easy it is when you
don't want it to. :-) In any case, if anyone has a foolproof
incantation to trick the optimizer into running code which will
deliberately cause a crash, I am interested.
It's probably a bit verbose, but it will crash when built with -O3:
#include <stdlib.h>
int bar(int a, char ** argv) {
argv[a][0] = '\0';
return 5;
}
int main(int argc, char ** argv) {
int a;
a = 4;
a += argc;
return bar(a, NULL);
}
Thank you.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
@apple.com
This email sent to email@hidden
--
Rick Altherr
Architecture and Performance Group
email@hidden
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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