Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
Re: Using atos & reading crash logs
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Using atos & reading crash logs




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

References: 
 >Using atos & reading crash logs (From: Eric Gorr <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2011 Apple Inc. All rights reserved.