On Nov 20, 2008, at 10:51 AM, Rick Altherr wrote: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
When you build with a dSYM, the symbol table is still in the binary unless you manually run strip. If atos finds entries in the symbol table, it will use those unless it finds entries in the dSYM.
I have my project configured as described in http://developer.apple.com/tools/xcode/symbolizingcrashdumps.html, that is:
Deployment Postprocessing: YES
Strip Linked Product: YES
Use Separate Strip: YES
Strip Debug Symbols During Copy: NO
When I run strings on my release build, it has only what I would expect to be there out of necessity, when I use dwarfdump on the application executable it has nothing, so I'm assuming it is getting stripped? And if I understand you correctly, it should either find the symbol in the binary or in the dSYM? But it's not finding method names in either, that's my problem.
Xcode 3.1 is required for atos to load symbol names from the dSYM. In Xcode 3.0, it will only use the dSYM for source line information.
I am using Xcode 3.1.
A few things you can check:
- Run dwarfdump --debug-info. It should spew lots of data including symbol names.
I ran dwarfdump with the --debug-info option and it outputs the exact same thing as the normal dump without that flag. The curious thing though is that this file contains of TAG_compile_uint's for AT_names corresponding to C files in statically linked library dependencies, it doesn't contain any of my Cocoa app's files: not a single occurence of ".m" in the whole dump! This is true for both the alpa release and for that always-crashing version that *DID* show method information this morning.
HOWEVER, in messing around with this, symbols stopped working even on a new build! I haven't done anything differently, in both cases there was just a one line "printf((char*)1);" addition from the alpha release. But this morning a clean build showed the method names in the stack trace leading up to the segfault, and now it's just showing (unresolvable) hex codes!! Is this related somehow to the ambient temperature, or tide levels?
- See if your debug build has the symbol table present with nm
I'm a little confused what the debug build has to do with any of this, but I had it compile with the Debug configuration I've been using and it did indeed have more symbols than my Release build. I've never had a lot of trouble with symbols in my debug builds besides the usual intermittent Xcode debugger snafus.
- Try using atos from Xcode 3.1 or later
I have Xcode 3.1 installed, and the two copies of of atos I could find (/usr/bin/atos and /Developer/usr/bin/atos) are identical. How do I check what version it is? The md5 sum of atos on my C2D iMac (Xcode 3.1) is 3cb02744baf03ec37d57e6687bda01e4, while the one on my Macbook (Xcode 3.1.1) is c6d133d7cf6b64dbc5ee10a65a03fd16. I copied the release app bundle to my Macbook, and atos there still fails to yield the method name like it was on the iMac this morning.
Thanks for your help, but it seems I've somehow done something in the meantime that *none* of my Release builds have the proper symbol table information. Is it normal to only have a subset of files showing up in the dwarfdump output, and if not how would atos have been resolving symbols this morning when the .dSYM files never did have records for my .m files?
thanks, -natevw |