I whined about the useless state of symbolification the other week and got a
grand total of sod all help. The latest Xcode claims to have clicky boxes to
select the version of your build and load all the good bits automatically and
drop you right in the code. As long as you are using testflight and
distributing via the store and .. my recent experience I’m very skeptical. I
also don’t know why Xcode isn’t able to load up a crashlog, do something
intelligent with a simple gui, even a slightly manual one, and get you 85% of
the way there. <rant off>
Anyway I did some work at the time and wrote some notes and kept them - they’re
pretty sparse but the idea was something like this
1) I assume you have xcarchives or dsyms in a directory somewhere. At least to
the point you have
<somedirectory>/<appname>*/dSYMs/<appname>.app.dSYM/Contents/Resources/Dwarf/<appname>
2) in your crashlog you have a UUID. I think I just looked at the crash report
but there’s probably a better way.
First job is to find some DSYMS for your crash, you want the one with the
correct UUID, so over all that huge pile of files in 1) you run …
symbols -uuid <somdirectory>/<appname>*/…. etc etc
You get list of UUIDs to paths. Match the UUID, now you know which dSYMs you
want, get the full path. In my particular case on that particular day it was
(deep breath)
/Users/rols/Library/Developer/Xcode/Archives/2014-09-20/ble-sniffer-os_Package\
20-9-14\ 12.29\
pm.xcarchive/dSYMs/ble-sniffer-osx.app.dSYM/Contents/Resources/DWARF/ble-sniffer-osx
The crashlog in this instance was
/Users/rols/Library/Logs/DiagnosticReports/ble-sniffer-osx_2015-05-20-145530_Rols-MacBook-Pro-Retina.crash
so now run lldb
> lldb
and import the crashlog module (if you are on iOS I don’t know which you
import, this was OSX)
> command script import lldb.macosx.crashlog
next you need to create a target - I have no clue at all how to do that
properly so I just import the crashlog which will then be entirely
unsymbolicated but creates one
> crashlog
/Users/rols/Library/Logs/DiagnosticReports/ble-sniffer-osx_2015-05-20-145530_Rols-MacBook-Pro-Retina.crash
Hopefully you’ll get something, just not anything with any symbols in it, next
job is to import the dsym file
> add-dsym
/Users/rols/Library/Developer/Xcode/Archives/2014-09-20/ble-sniffer-os_Package\
20-9-14\ 12.29\
pm.xcarchive/dSYMs/ble-sniffer-osx.app.dSYM/Contents/Resources/DWARF/ble-sniffer-osx
and then because I don’t really know how it works, I do the crashlog line again
because that’s all I could figure out
> crashlog
/Users/rols/Library/Logs/DiagnosticReports/ble-sniffer-osx_2015-05-20-145530_Rols-MacBook-Pro-Retina.crash
At that point I had a properly symbolicated crashlog, with method and line
numbers and I believe some assembler at the crash site. It was enough to point
me directly to the bug in the frameworks which was crashing my app .. joy.
> On 18 Jun 2015, at 04:41, Doug Hill <[email protected]> wrote:
>
> I have a crash report from our QA tester that I’m trying to reproduce/debug.
> I’m now going through the hoops to symbolicate the crash report.
>
> Apple documentation says to drag the crash report into the Devices window in
> Xcode and it will symbolicate automagically. I see the crash report in the
> list but no symbols. It doesn’t happen possibly because the app wasn’t built
> on my local machine, it was built on our build server?? Yes, I also tried
> Resymbolicate, still no symbols.
>
> OK, now I try to go the manual route, using atos. I put the sym file in the
> same directory as the executable and run:
>
> atos -o /Path/to/my/executable 0x00000001006341f8
> 0x00000001006341f8 (in Chartcube)
>
> Nothing.
>
> I try some other addresses for another thread and I get seemingly good
> results:
>
> atos -o Chartcube 0x000000010047cbe0
> -[SChartDateFrequency setDefaults] (in Chartcube) + 32
>
> So, it at least sort of works.
>
> Maybe atos is confused for some reason, so I’ll try lldb to lookup this
> address:
>
> (lldb) image lookup -v --address 0x000000010047cbe0
> Address: Chartcube[0x000000010047cbe0] (Chartcube.__TEXT.__text +
> 4680612)
> Summary: Chartcube`-[SChartDateFrequency setDefaults] + 32
> Module: file = "/Path/to/my/executable, arch = "arm64"
>
> This works too. How about the problematic address:
>
> (lldb) image lookup -v --address 0x0000000100634488
> Address: Chartcube[0x0000000100634488]
> (Chartcube.__TEXT.__objc_methname + 44672)
> Summary: "re:TouchPoint:"
> Module: file = "/Path/to/my/executable", arch = "arm64"
>
> Uh oh, this looks like a completely bogus symbol. This is confirmed when I
> try another one:
>
> (lldb) image lookup -v --address 0x0000000100633fd8
> Address: Chartcube[0x0000000100633fd8]
> (Chartcube.__TEXT.__objc_methname + 43472)
> Summary: "ickStyle"
> Module: file = "/Path/to/my/executable", arch = "arm64"
>
> There isn’t an offset into the symbol, and it’s showing an objc_methname
> which I believe is a selector. Why???
>
> Looking at the address in the crash report I see:
>
> 16 Chartcube 0x0000000100634488 0x1000ec000 + 5538952
> 17 Chartcube 0x0000000100633fd8 0x1000ec000 + 5537752
>
> Those are some suspiciously huge offsets which leads me to believe the stack
> might be borked, but who knows.
>
> Anyone have ideas on why I’m not able to get correct symbols?
>
> Thanks.
>
> Doug Hill
> http://chartcube <http://chartcube/>.com/
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/xcode-users/archive%40mail-archive.com
This email sent to [email protected]
