• 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: How do you get Xcode to symbolicate an OS X crash report?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How do you get Xcode to symbolicate an OS X crash report?


  • Subject: Re: How do you get Xcode to symbolicate an OS X crash report?
  • From: Nivek Research <email@hidden>
  • Date: Mon, 28 Jul 2014 09:12:07 -0500

While I agree that http://lldb.llvm.org/symbols.html is a great read and possibly the ideal solution I build and archive my OS X products using Xcode 5 and, unfortunately, I’ve found no way to have all the necessarily plists automatically included in the xcarchive. I’d love to be educated if someone knows how to make that happen.

However, I have written a perl script that in conjunction with Spotlight redirects the crashlog python script to the correct images for symbols. The script needs to be named dsymForUUID and in the executable path for the crashlog python script to find it. If one is using xcarchives and Spotlight indexing the script should work unmodified. The caveat is that I believe by default xcarchives are not indexed by Spotlight in their default location in ~/Library. That can be remedied by either telling Xcode to archive someplace other than the ~/Library directory or coping the archives to another location outside the ~/Library directory. Again if anyone knows how to make Spotlight index the archives in ~/Library I’d love to know.

I’ve included the script below.
—kevin

#!/usr/bin/perl

# Copyright (c) 2014 B. Kevin Hardman

# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at

# http://www.apache.org/licenses/LICENSE-2.0

# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.

my ($uuid) = @ARGV;

my ($path) = qx(mdfind "com_apple_xcode_dsym_uuids == $uuid");
exit if $path !~ m/\.xcarchive$/;
chomp $path;
$path = "$path/dSYMs";

opendir(DIR, "$path") || die "Can't open directory $path: $!\n";
my @files = readdir(DIR);
closedir(DIR);

print "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n";
print "<!DOCTYPE plist PUBLIC \"-//Apple//DTD PLIST 1.0//EN\" \"http://www.apple.com/DTDs/PropertyList-1.0.dtd\">\n";
print "<plist version=\"1.0\">\n";

print "<dict>\n";
foreach my $file (@files) {
$file = "$path/$file";
my ($_) = qx(dwarfdump -u "$file");
next if $_ !~ /DWARF/;
my ($uuid, $arch, $executable) = m/^UUID: ([^ ]*) \(([^)]*)\) (.*)$/;

print "<key>$uuid</key>\n";
print "<dict>\n";
print "<key>DBGArchitecture</key>\n";
print "<string>$arch</string>\n";
print "<key>DBGDSYMPath</key>\n";
print "<string>$file</string>\n";
print "<key>DBGSymbolRichExecutable</key>\n";
print "<string>$executable</string>\n";
print "</dict>\n";
}
print "</dict>\n";

print "</plist>\n";


On Jul 27, 2014, at 2:00 PM, email@hidden wrote:

On 26 Jul 2014, at 8:07 am, email@hidden wrote:

The crashlog command (actually a Python script) parses the crashlog, reads the UUID's for all the binaries from the images list at the end of the crash log, and then uses the "DebugSymbols" framework to locate the dSYM given the UUID.  You can read more about how DebugSymbols works here:

http://lldb.llvm.org/symbols.html

Jim


Today I had a problem getting crashlog to find the binaries. The last time, when it worked, the Application was run from, and crashed from, the /Applications directory and that path was buried in the crash report and so were the UUIDs and it found the debug symbols. At that time the version in /Applications was the same one that crashed. 

Today I ran the exact same binary but I ran it from the archived build location because the one I have installed in /Applications has moved forwards and I wanted to reproduce the old crash again. That crash had the archived binary location from that run embedded in it, except that the home directory was anonymised to /Users/USER/.. The UUID on the binary however was exactly the same as before, because it really was the same binary. 

However crashlog failed to load the symbols this time. The error was 

Getting symbols for CDB41485-41C5-312E-B79F-19E9D3EC4F27 /Users/USER/Library/Developer/… error: unable to locate main executable (None) "/Users/USER/Library/Developer/Xcode/…


So it seems that the path buried in the crash log has to point to an executable or possibly the correct version of the executable before it will even get to the point of looking for the debug symbols by UUID. 

That makes me wonder, what if you run crashlog on a normal /Applications/.. crash but the binary in your /Applications/.. directory is newer, which happens a lot, crash reports often come in ages late. Will crash log eventually load the correct binary, the one which goes with the debug symbols or will it load the wrong application binary and the right debug symbols and have a huge mismatch?  

Better still, is there a way I can tell crashlog which actual binary it should load and where to find the debug symbols? I could go edit all the paths in the crash log to point to the archived app location but that seems a bit heavy. 

 _______________________________________________
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

  • Prev by Date: Re: How do you get Xcode to symbolicate an OS X crash report?
  • Next by Date: Should the Simulator talk?
  • Previous by thread: Re: How do you get Xcode to symbolicate an OS X crash report?
  • Next by thread: App helpbooks
  • Index(es):
    • Date
    • Thread