Re: Nothing (reliably) helpful from atos + dSYM
Re: Nothing (reliably) helpful from atos + dSYM
- Subject: Re: Nothing (reliably) helpful from atos + dSYM
- From: Jason Molenda <email@hidden>
- Date: Thu, 20 Nov 2008 16:43:51 -0800
Nate,
It sounds like your dSYM may not contain all the information you think
it contains. Maybe your Release target in your Xcode project doesn't
emit debug info? Here's an easy way to check:
dwarfdump -arch x86_64 -r 1 Mercatalog.app.dSYM
this will show you the top-level debug info entries in the dSYM -
there should be one for every source file (the DW_AT_name fields). My
guess is that you will see less debug info than you'd expect. Either
the debug info was never generated or the binary was stripped before
dsymutil was run to create the dSYM bundle.
Another simple check is to just look at the file sizes of the dSYM
binary (or du(1) the dSYM bundle) -- if the dSYM for your release
build was very small compared to the dSYM that you built today, you've
got your answer.
You can expect to see three types of answers from atos. If there are
no symbols present in the binary at all and no debug info, you'll get
output like
/Developer/user/bin/atos -arch x86_64 -o Mercatalog.app/Contents/
MacOS/Mercatalog 0x0000000100020ff4
0x0000000100020ff4 (in Mercatalog)
If you have an unstripped binary with its symbols still present, but
no debug info, you'll get byte offsets from the function symbols, e.g.
% atos -arch x86_64 -o b 0x100000f12
main (in b) + 0
%
If you have a dSYM with the appropriate debug info, you'll get a file
and line number:
% atos -arch x86_64 -o b.dSYM/Contents/Resources/DWARF/b 0x100000f12
main (in b) (b.c:3)
%
atos may be able to locate the dSYM bundle automatically given just
the binary - I can't remember what lookup schemes it may be using. If
nothing else, just specify the dSYM debug info directly like I did here.
J
On Nov 20, 2008, at 10:23 AM, Nathan Vander Wilt wrote:
I recently sent out a release of an upcoming product to some alpha
testers, who found a few crashers. They sent me the crashlogs and
since I had generated dSYM info for the build, I gave atos a shot.
From the directory where I had both Mercatalog.app and
Mercatalog.app.dSYM, I tried:
/Developer/user/bin/atos -arch x86_64 -o Mercatalog.app/Contents/
MacOS/Mercatalog 0x0000000100020ff4
but all I got back was the almost-useless:
0x0000000100020ff4 (in Mercatalog)
I used dwarfdump --uuid to compare the UUIDs between the .dSYM and
the app executable and they matched.
I also tried using:
dwarfdump Mercatalog.app.dSYM --arch=x86_64 --lookup=
0x0000000100020ff4
but that didn't find anything either, although maybe I'm using that
wrong (It outputs "Looking up address: 0x00000000ffffffff in the
debug information...not found.", which isn't what I wanted it to
look up anyway...)
The odd thing is that I did get atos to work just fine (with the
exact same project.pbxproj) when I force a crash by adding a printf
((char*)1) to the otherwise unchanged source code. Why would it work
with the build I just made this morning, but not the copy of the
build I sent out last week? Does atos break if the executable/
symbols are moved from the original build path? I need a reliable
way of getting symbol information for released products.
thanks,
-natevw
_______________________________________________
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
_______________________________________________
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