I am facing some problem in symbolicating my crash log.
I followed all the steps as answered by naveenshan in this thread.
But once I execute the line
atos -arch armv7 -o 'app name.app'/'app name' 0x0003b508,
it just throws me back the address 0x0003b508 back on the console.
I am not able to figure out why its not symbolicating my crash log.
I even tried symbolicating by drag and drop my crash log into device logs in my xcode. But even that doesnt seem to work.
You have to have the exact dSYM that was generated along the build that is installed on the device and generates the crash report.
Please follow the steps explained in this answer (even though the original problems are not the same, the steps help identify if you have the correct dSYM): Symbolicate Crash Log when App Name Contains Apostrophe and Space (Deployed App)
Executing the line with atos you posted, is most likely to return nothing useful, since the address given as a parameter does not have to exist in your app. You have to use a proper address taken from the crash report and calculated properly as detailed here: iOS crash reports: atos not working as expected
Best approach is the follow the steps written in the first linked post.
Related
I have been observing this that when ever my app crashes i get the crash log and try to symbolicate it but following happen
When I use xcode to symbolicate, it never symbolicates the addresses of the crash
When I use atos command specified developer.apple.com technotes it either gives some other class function name that does not have to do any thing with the crash
I have used other methods like symbolicatecrash script but the result is same as before.
I also tried solution given stackoverflow.com/questions/7932992 but did not succeed
I created a demo crash and tried to change my scheme of the app for "Run" and changed "build configuration" to "release" to check if the crashes symbolicate when I run the app directly to device, I test the app, the demo crash occurs and in this case the crahes get symbolicated.
I created a demo crash in a new app and created an archive and export IPA, used this ipa in a device to recreate that crash but still xcode could not symbolicate that crash.
I don't get why is it behaving this way,
I looked into the archives to find my dSYM file and can locate it there but could not symbolicate it using any of the processes stated above.
A guidance will be helpful!
I was working with code back to see if there can be any impact of bitcode with help of a friend, found that while exporting archive to IPA, it asks me to rebuild with bitcode (which was checked) I just tried and unchecked it to create the IPA and this time my app crash logs were symbolicated, I still don't know why this happens because apple recomends to rebuild with bitcode while submitting apps.
I am looking for more answeres for why is it happening?
Will keep you posted (also a enlighten me if there are any misses.)
Although, I have run the script to upload .dsym file, it shows this error: "This stack trace is unsymbolicated. To obtain symbols, you need to upload your dSYM file via the command line tool."
Also, even if I force a crash using the method provided, it does not show up under analytics. I am on ParseCrashReporting 1.9.2.
It used to work reliably earlier, about 3-4 months back. Not any more.
Before I explain let me just say I have looked all over and tried many many ways of symbolicating the crash log.
MY ISSUE: When my app (on my iPhone) is ran from Xcode, the app never crashes. When my app is ran on my phone, and not connected to my computer at all, it crashes in the same spot every-time.
MY SYMBOLICATE ISSUE: I have retrieved the crash file from my phone, i've got the .dSYM file from the archived build and the UUID's don't match up, so I can't symbolicate the crash and find the line of code that's causing the problem.
MY GOAL: To resolve this error. It seems the best way to do it is by the Symbolicate command, but maybe there is something new with Xcode 7 that makes symbolicating a crash file from a device much easier?
Hope this is clear. Thanks so much!
Soo, with TestFlight's end it has become even more pressing to be able to fully understand iOS crashlogs.
There are numerous questions here at SO about this topic but in my experience none of the solutions provided enough insight into the crash itself.
There still seems to be quite a confusion about this in the iOS world.
For the sake of completion here are the methods and steps I found and took.
(Disclamer: I had access to everyting: the .app file, the .dSYM and .crash files)
1| symbolicatecrash - command line utility
define the developer directory: export DEVELOPER_DIR="/Applications/Xcode.app/Contents/Developer”
install the utility from its original directory: sudo cp /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKitBase.framework/Versions/A/Resources/symbolicatecrash /usr/bin
put the dSYM file, the .app file and the .crash file in the same folder
symbolicatecrash “FILENAME.crash" "FILENAME.app" "FILENAME.app.dSYM"
2| atos - command line utility
open crash file, get the memory address one line at a time from the stack trace, like so: 8 NAME_OF_MY_APP 0x000ad031 0xa7000 + 24625
and use atos to symbolicate that one line: atos -arch armv7 -o NAME_OF_MY_APP.app/NAME_OF_MY_APP 0x000ad031 0xa7000 + 24625
3| gdb
there is a great post from Jerry Krinock for a third option... but it uses gdb and gdb is no longer available in OS X Mavericks: http://www.cocoabuilder.com/archive/xcode/312725-can-symbolicate-crash-reports.html
Now either I'm dumb, stupid, or both but for me, the problem with all these methods is that they inconsistent.
In my experience, symbolicating with symbolicatecrash will give us the method names for all the stack trace, but no line numbers and little to no info about the exception thrown.
Atos is a bit more descriptive, but still no exception description and you have to manually do this for all the lines you want symbolicated.
Also, atos sometimes points to method calls that are not in output of symbolicatecrash...
When I uploaded a build to TestFlight along with the .dSYM they could give me precise method names, line numbers and exception description that I just cannot find in these symbolications.
Is the exception description even in the crashlog?
Do we have to implement an unhandled exception handler within the app and send the reports "home" (ie to a web server?) to have access to what exception was thrown, where?
symbolicatecrash - command line utility
You are calling the script wrong, it should be:
symbolicatecrash “FILENAME.crash" "NAME_OF_MY_APP.app.dSYM"
atos - command line utility
This call is also wrong:
atos -arch armv7 -l LOAD_ADDRESS_OF_THE_APP -o NAME_OF_MY_APP.app.dSYM 0x000ad031
Where LOAD_ADDRESS_OF_THE_APP is the first address shown in the Binary Images section for your app. See also: iOS crash reports: atos not working as expected
Now regarding the additional questions/remarks:
Line number not appearing using symbolicatecrash:
This is because you passed along the app binary, which mostly has all symbols stripped (due to size) and even if the symbols would not be stripped it would never show line numbers. Always use the dSYM for symbolication if you have it.
Exception description missing:
In most cases, Apple's iOS crash reports do not provide the Application Specific Information block in the reports which would contain that information. If you only have Apples crash reports, there is nothing you can do.
Some additional information:
Symbolication system calls
You will need the symbols of the specific CPU architecture and iOS version the crash report was created with. So you would need at least an armv7 device and an arm64 device with the specific iOS version and having those at least once connected to Xcode that it could import the symbols. Otherwise there will be symbols left unsymbolicated in the report.
Let Xcode symbolicate it
If your system is setup correctly, all you need to do is drag the crash report into the top Devices Logs entry in the Xcode organizer and it will call symbolicatecrash for you and find the correct dSYM via Spotlight. (Requires the dSYMs folder to be indexed by Spotlight)
Alternatives to collect crash reports
There are multiple alternatives out there to collect crash reports. Open Source solutions, free services and paid services that provide SDKs to collect the crash reports in your app and send them to a server, symbolicate and group them automatically. (Disclaimer: I am the developer of QuincyKit Open Source project and Co-Founder of HockeyApp.net service)
We're using TestFlight to send out pilots of our app.
There's a part of the app that is crashing, and we had a lot of trouble reproducing the crash. The code their is fairly simple.
It turns out that the users who got the App via TestFlight get the crash, while if you build the app and install it using the IDE it doesn't crash!
Anyone have ideas about what might be causing this?
Any ideas for workarounds? We don't want to stop using TestFlight.
Make sure to build your app in Release Mode not in Debug. The app may only crash when in Release.
The first thing I'd try is to map the crash stack trace to function names in your application. This may yield useful insight into the nature of the crash:
As soon as a crash is reported request the crash log. This can be obtained through Xcode's organizer or if that's not an option it can be screen-captured from the iPhone's Settings -> General -> About -> Diagnostics & Usage -> Diagnostic & Usage Data. Scroll to the app name or the section LatestCrash-AppName.plist.
Although you can in theory symbolicate a crash, I find the procedure described below a foolproof way to get symbols from the stack. Convert all stack addresses for the crashing thread into method names.
Optionally request the iDevice syslog. This may include assertion failure messages which are also invaluable. Note that this should be done as quickly as possible as the syslog only holds so many entries before they get dropped. You can use the Organizer or the cmd line idevicesyslog to obtain this.
Manual symbolication:
This will work as long as your builds have debug information.
Obtain the _exact_same_ .ipa that crashed. If you didn't save it you can download it from the device by using iFunBox or the cmd line ideviceinstaller utility.
Unzip the .ipa
Run the following command on the executable file (Payload/AppName.app/AppName):
otool -tv AppName.app | c++filt > listing.asm
Wait while the previous step completes (may take a while). The generated listing.asm file will be several megabytes long.
Using an editor that can handle large files search listing.asm for the addresses listed in the stack trace. Note that the addresses may be a few bytes off (usually pointing 3 or so bytes ahead). Also, addresses that aren't found in listing.asm indicate addresses in iOS libraries. Ignore those for now.
Of course, if you're able to symbolicate, you can skip this procedure.
Good luck debugging!
We had a similar problem. The issue with us was static libraries. When we built the app from scratch and went to testflight, it was crashing but from the IDE it wasn't. The crash was because the static libraries did not get included when doing a build, but was getting included if I connected the iPad direct and used XCode to install.
A simple test will prove this:-
1.) Instead of building from IDE, create a .app file and then load it via iTunes and check if you are getting the crash.
We worked around this by creating the .iPA manually, that is creating the .app then making a Payload folder and putting the .app in it along with the info.plist.
Then things began to work in Testflight as well.