I'm studying iOS crash analysis. Now, I need to import crashlog files into LLDB. As WWDC18 Session 414 said, I now have a copy of myApp, dSYM, xxx.crash. Run the following command in iTerm2.app:
$ lldb
(lldb) command script import lldb.macosx.crashlog
(lldb) crashlog /path/xxxx.crash
However, the stack trace file is not available and there is only a lot of error like:
error: unable to locate any executables from the crash log
Did I use it wrong? What is the correct method of use?
I've recently had the same issue. Unfortunately, in it's current state the crashlog script appears to expect the original binary to be around, but we can "trick" it by either:
Copying the binary from inside the .dSYM/Contents/Resources/DWARF/ into the path it is expecting it (found on the .crash file, something like /private/var/containers/Bundle/Application/SOME-UUID/MyApp.app/MyApp)
Editing the paths (not just the initial one) in the .crash file before symbolicating to the path of the binary (e.g. ~/MyFolder/MyApp.app/...).
Hope this helps! 🙏
Related
I am using crittercism crash reporting tool . Initially it is working fine , but now it showing error
CRITTERCISM_DIR_NAME: No such file or directory
This error suggests that the path of the crittercism library placed on your system is not specified. We usually encounter this message while uploading dSYM using the build script. By following this method, we are supposed to mention the APP ID, APP Key and Source path of the script which might be missed here and caused the error. You may refer to the following article for detailed information :
https://docs.apteligent.com/ios/ios_dsym.html#configuring-crash-symbolication
I've read through a number of similar questions here about Parse Crash Reporting, and got a couple of hints that helped. But I am still unable to get the symbol file uploaded.
I added the script to XCode exactly as per instructions on the Parse Website. When the app builds, the script seems to run, and all the right messages are being displayed.
and
I added the time-delayed forced Exception to the app, in the suggested place. I ensured that CrashReporting was enabled. I added the Parse framework to the project via CocoaPods; it's there, and the app compiles without error or warning. I did the sequence of one crash, restart, second crash, wait a few minutes, refresh the Parse Dashboard.
But Parse thinks otherwise:
OK, fine. So i did a manual push of the file, via CLI from Terminal. First attempt failed because I wasn't uploading the DWARF file. Corrected that. Now it says it cant' find the file or directory.
Here's my folder on my machine, where the file is located:
And here's the command line, with the command and result:
So the CLI maybe is thinking that the filename isn't a file; I tried changing the name by adding a ".bin" extension.
Then I got a different error: "Do not understand symbol files at:" followed by the full path to the file. I even tried enclosing the full path in single quotes, inside the double quotes; same not-found error.
I have the latest Parse CLI downloaded. I am running the command "parse symbols -p " from the app's Cloud Code directory (an existing directory that had been set up earlier to use other Parse Cloud Code features).
What else to add? Running XCode 6.4, Objective-C app, I checked various other Build Settings to ensure that symbols were being generated. The file is 30Mb in size and opening it reveals what is clearly a binary file, whose contents do look like they're symbols from a compiler - recognizable names of classes, etc.
This is just a test app, and I'm testing out the Parse crash reporting, rather than signing up for another service, like New Relic or any of the other ones; I figure, I'm using Parse for other stuff, why not use its Crash Reporting...
Anyone have any idea what I'm doing wrong here? I just can't see it.
I'm trying to symbolicate a crash dump for an iOS app buit using Xamarin.iOS. I am seeing a lot of warning about not being able to find symbols for system binary images such a Foundation, and the output from symbolicate is ultimately missing most of the information that I need.
I'm following the process described here. I have put MyApp.app, MyApp.app.dSYM, and the crash log into a directory and run symbolicate -o crash.txt "crashreport.crash" "MyApp.app". The output crash.txt contains no symbols, and I see a lot of errors in the symbolicate console output. For example:
Finding Symbols:
.fetching symbol file for Foundation--[undef]
Searching []...-- NO MATCH
Searching in Spotlight for dsym with UUID of e596bd80bcc83f15aca36a7ef014f457
Running mdfind "com_apple_xcode_dsym_uuids == E596BD80-BCC8-3F15-ACA3-6A7EF014F457"
#dsym_paths = ( )
#exec_names = ( )
Did not find executable for dsym
## Warning: Can't find any unstripped binary that matches version of /System/Library/Frameworks/Foundation.framework/Foundation
The full output is at http://pastebin.com/W1KP1iTR
I have used dwarfdump to verify that the UUID in MyApp.pSYM is the same as the one in the crash dump.
I'm using Xamarin studio 5.7.1 on with xcode 6.1.1.
Can anyone suggest what is going wrong here?
Apple's symbolicate tool requires that you add all executables and mach-o binaries to Spotlight database prior to querying for symbols.
This of course a tedious job that is required. I could never find how to remove it from the index, or to know what the queue has been completed and the binary with its UUIDs are indexed.
Plug: I wrote this symbolicate-pro tool.
Here's a program I wrote for TestFairy (the company). It's called symbolicate-pro and it has a few key differences that Apple's symbolicate:
It does not require any indexing.
You can specify directories where your iOS symbols are located.
It's 10x faster.
And if you get otool compiled for another OS, it can run on other platforms than Mac.
TestFairy uses it for its production and is updating when iOS changes the crash reports.
You can find it on github at: https://github.com/testfairy/symbolicatecrash-pro
Hope this helps ;)
I am interested in getting a readable stack-trace when my iPhone/iPad crashes. I would like to send this information to our server once it is trapped. I know there are tools like Crashlytics that do this very well, but we would like to stay away from any 3rd party tools if at all possible. The only way I know to get this info is to manually do it by retrieving the and then have that file symbolicated on a Mac before it can be analyzed. Even doing this can be troublesome if you don't have a copy of the original application binary and the .dSYM file that was generated when that binary was built. I believe Crashlytics does this somehow without the actual binary or the .dSYM file which leads me to believe that a simple stack trace can be generate programmatically. Has anyone done this or have any pointers as to how I could do this within Objective C so that I could send that information to our servers for Error reporting?
Is it at all possible to get a create a readable stack-trace within Objective C on my iOS device without having to first send that file to a Mac with both the actual binary or the .dSYM file?
Just use
[NSThread callStackSymbols]
I have an app on the App Store that is crashing. I have tried several of the solutions on SO to symbolicate my app, using at different times the Organizer, the Terminal, and Instruments. Nothing has worked so far - the lines in the reports from the methods in my app are never symbolicated, even when the lines for Apple methods are. After looking around for a while, it seems as though this might have something to do with the app name, which is along the lines of "Angie's List" - with both an apostrophe and a space. It is too late to change the app name now as it is live on the store. I haven't seen a solution to this anywhere and would appreciate a shove in the right direction.
Usually the app name doesn't matter, unless there is a bug in the symbolication script which I doubt. Did you check if you have the correct dSYM available?
If you scroll down your latest crash log, check the 1st line below Binary Images, it will look like this
0x1000 - 0x24cfff +YourApp armv7 <f6012c517d783486ab53e45d948b92a2> /var/mobile/Applications/A8EC3C1F-44AF-169A-BC0E-FBBC0F04CDF5/YourApp.app/YourApp
f6012c517d783486ab53e45d948b92a2 is the UUID of the executable the caused the crash.
You can find the correct dSYM using the terminal as follows:
mdfind "com_apple_xcode_dsym_uuids == F6012C51-7D78-3486-AB53-E45D948B92A2"
The string F6012C51-7D78-3486-AB53-E45D948B92A2 is the above string reformatted to uppercase and 8-4-4-4-12 groups. I guess this command will not return anything.
If you have a dSYM (e.g. in an .xcarchive), you can check its UUID in the terminal as follows:
dwarfdump --uuid YourApp.app.dSYM
If symbolication doesn't work automatically, you can try to do it manually by following the instructions posted here: iOS crash reports: atos not working as expected
If the application has special characters like spaces or apostrophe's in it, the default Apple toolchain will not be able to symbolicate it. The reason is that the tool otool, which being used in the toolchain, can't handle that. No matter how you pass the filename. So to fix this, you have to do the following:
Rename the dSYM package and remove all special chars, e.g. from My App's.app.dSYM to MyApps.app.dSYM
Open the content inside the package and navigate down to Contents/Resources/DWARF
Rename the file in there as you did above
Now try again. Best way to avoid all this: NEVER use special chars in your apps name. If you want the adjust the name that appears on the screen, use CFBundleDisplayName or the corresponding plist entries.