Using atos & reading crash logs
Using atos & reading crash logs
- Subject: Using atos & reading crash logs
- From: Eric Gorr <email@hidden>
- Date: Wed, 11 Feb 2009 17:38:53 -0500
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 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.
*****
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.
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:
This email sent to email@hidden