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.
Related
I added firebase crash reporting to my iOS project (added pod, added build phase script, added json to project, ...).
When i run my app, i see in my console:
Firebase Crash Reporting: Successfully enabled
For testing, i insert fatalError() in my code after my FIRApp.configure() code (as suggested here: https://firebase.google.com/docs/crash/ios#create_your_first_error).
No crash reports are sent at my next app launch (that doesn't crash). I see nothing in my xcode console and nothing in my web console.
Not an immediate solution, but some diagnostic tricks that may help locate the problem:
Make sure that the debugger is DISABLED when you generate the crash in the simulator or attached device, or the debugger will grab the crash before FCR does. Launch the app (⌘R) in Xcode, stop the debugger (⌘.) in Xcode, and re-launch the app manually in the simulator or on the device.
If you are using the simulator and you follow the above instructions, then you should see the raw crash dumps produced if you execute the command find ~/Library/Developer/CoreSimulator -path '*/FCRDumps/*.dmp' -ls (note that unprocessed crashes from other test apps will also be displayed).
If you see one or more dump files with the right timestamp, then you should get a successful upload the next time the app launches. Remove the fatalError() line, then rebuild and relaunch. The .dmp files in that container should soon disappear, replaced by .crash files (use find ~/Library/Developer/CoreSimulator -path '*/FCRCrashQueue/*.crash' -ls to find them). The crash files will be deleted one at a time after they successfully upload.
I have an app in beta using TestFlight and I have been noticing crash reports appearing.
most of the reports are this
If I click on the button Open in project in the Organizer it takes me no where
This appears to be an internal crash correct?
How can I find out what UIBarButtonItem is causing the crash?
I Hope this will help you: Apple doc Crash Report , as you can see in the doc in the Listing 4 the crash report is fully symbolicated , Listing 6 shows partially symbolicated crash reports which looks like your case
From Apple Doc
You must keep both the application binary and the .dSYM file in order to be able to fully symbolicate crash reports. You should archive these files for every build that you submit to iTunes Connect. The .dSYM and application binary are specifically tied together on a per-build-basis, and subsequent builds, even from the same source files, will not interoperate with files from other builds. If you use Xcode's Build and Archive command then they will be placed in a suitable location automatically. Otherwise any location searchable by Spotlight (such as your home directory) is fine.
For more information about this you can check portion after Listing 6 in Symbolication
you can use crashlytics for identifying where the app is crashed.It will give the Controller name and line number of code also.
https://docs.fabric.io/ios/index.html Document
Easy to add your project also
I have an app that is already in the App Store and I got a crash report that is a unsymbolicated. I tried to upload the .dSYM file using the following procedure, but Parse is still showing me the unsymbolicated crash report. I am wondering if I am doing anything wrong.
Let's say the app is named MyApp
In Xcode, I open the Organizer using Window > Organizer
I locate my latest MyApp Archive, and I right click on it then Show in Finder
I right click on MyApp.xcarchive file and choose Show Package Contents
I navigate into the dSYMs folder and get the directory (I also see here MyApp.app.dSYM file)
In Terminal, I upload the dSYM file using this:
I cd into my parse cloud folder which is in my project folder
Then I type the following:
parse symbols MyApp --path="/Users/EmadToukan/Library/Developer/Xcode/Archives/2015-08-15/MyApp 2015-08-15, 7.28 PM.xcarchive/dSYMs/MyApp.app.dSYM"
When I hit enter, I get the following:
Uploading iOS symbol files...
Uploaded symbol files.
When I refresh my Parse Analytics page, it still says that the crash report is unsymbolicated. Any ideas why this is happening?
I submitted this as a comment originally because I didn't think I was seeing correct results. Now I realize that I am.
So what you need to do is upload the file found in DWARF directory of your archive. This can be found at dSYM/xarchive/DWARF/app_name, where "app_name" will actually be the file you want to upload.
Once you do this, from what I can tell from Parse's docs, previous crashes that were unsymbolicated will not be symbolicated. Instead, a new crash will be generated with symbols. It's a bit confusing because the duplicate, unsym crashes remain there afterwards. You can find this information on Parse's website here
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.