• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: More symbolicate *$#*^!
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: More symbolicate *$#*^!

  • Subject: Re: More symbolicate *$#*^!
  • From: Roland King <email@hidden>
  • Date: Thu, 18 Jun 2015 07:44:45 +0800
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@hidden> 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.com/


 _______________________________________________
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: 
 >More symbolicate *$#*^! (From: Doug Hill <email@hidden>)

  • Prev by Date: More symbolicate *$#*^!
  • Next by Date: Re: LLDB "warning: got name from symbols: _XCDidPauseInDebugger" on every breakpoint
  • Previous by thread: More symbolicate *$#*^!
  • Next by thread: Re: More symbolicate *$#*^!
  • Index(es):
    • Date
    • Thread