Debugging crash from Device not connected to Xcode 7 - Symbolicate - ios

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!

Related

iOS Swift game crashing on everyones iPhone, except mine

I've been developing a small "Cookie Clicker" style game for a while now and all of the sudden, the app will instantly crash upon opening. It doesn't crash on my own phone that I've been running the tests on, however, anyone that downloads it from TestFlight cannot even open it. It runs perfectly on the Xcode simulator as well.
Out of desperation, I completely backtracked the update that started the crashes (deleted all the new code for the menu I was working on) but it STILL CRASHES.
I don't want to copy/paste the code here because it is 16,000+ lines and I don't even know which aspect could be affecting it. I am using Xcode 11 and Swift.
If anyone has encountered this problem before and knows even where to start looking for the problem, any help is appreciated.
You need to download the crashlogs from Testflight, re-sybolicate them, and see where it's crashing. Download them from https://appstoreconnect.apple.com/ where you manage TestFlight. Here's an example:
Inside the download is generally two files:
crashlog.crash -- this is the actual crash
feedback.json -- any input provided by the user when it crashed
The .crash file can be re-symbolicated in Xcode as needed and you can see exactly which line caused the crash.

Xcode cannot symbolicate my crash logs even though I have correct .dSYM file

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.)

iOS - Crashlytics - missing several crashes

I have problem with Crashlytics (and with crashes shown in Xcode -> Organizer) because I don't see many of crashes that I should. From testers I should have many crashes there but I don't have. I logged into iTunes Connect and get zipped dSYM files there and upload them to Crashlytics to see new crashes. But even if it said that there is one or more new crash after upload dSYM I dont see any new crash. It looks like most of crashes I dont see in Crashlytics. Why is that? I need to get logs/crashes from devices that runs app from TestFlight. I think with Objective-C and before bitcode it worked much better.
Edit:
Is it possible that in another tool (from 3rd party company) there would be crashes that aren't in Apple Organizer? I am asking if I should try more tools from other companies. Maybe some of crashes are because of memory. Is it possible that these crashes aren't in reports?
Thanks
Fabric shows 1 crash 'row' for each crash, the number of crashes is in the same row.
But remember, crashes are only send to crashlytics if the user opens the app again.
You could also test Crashlytics by using:
Crashlytics.sharedInstance().crash()
First make sure you have uploaded your dsym files to your crashlytics dashboard, Check this
Click on the encircled part
Then on your Xcode > Window > Organizer
Tap Download dSYMs, When the download is complete right click your Archive and click Show in Finder, then right click the package and tap Show Package Contents
Open the dSYMs folder, then you can just drag and drop those dSYMs to the Crashlytics Dashboard
I think that your problem is related to two things:
As Gerrit said in the other answer crashes are sent to Crashlytics if the user opens the app again;
The crashes in Xcode --> Organizer are displayed only if the user sets on the share of analytics with App Developers.
For more informations take a look at this link: Share analytics, diagnostics, and usage information with Apple.
If people doesn't share the analytics you won't see any crash.
EDIT: I found that your problem may also be related to the debugger...for more information check this thread and see if you can find your solution here --> Crashlytics is not sending Crash report from iPhone.
I hope to have been helpful!
If the application is crashing before the like in your AppDelegate where you are setting up Fabric/Crashlytics then the crashes are not going to get sent through properly.
It may also be that the crashes you are experiencing are being filed as Out-of-memory crashes by Crashlytics.

Forcing crash symbolication in crashes organizer and Xcode 7

Currently, my crash organizer looks as follows.
I have not really worked with crash logs before, but to me the crashes do not look symbolicated. I am unable to find where the app has crashed and for what reason. In addition, when I open the stack trace in the project, nothing is highlighted and I cannot tell and which line it crashed in the file. My question is: is there a way to symbolicate all these crashes from within the organizer, or must it be done through terminal?
Thanks.
What you're seeing is that the SDK classes like UITableView are symbolicated, but classes from your "YLSA" app are not. Both should be symbolicated automatically, but in my experience one or the other (or both) often do not symbolicate. I've been developing for iOS for five years and this has been a persistent problem through all the different Xcode versions.
I'm seeing the same problem as you in Xcode 7, but I was able to symbolicate my logs with this workaround:
In the list of crash logs, right-click the desired log and select Show in Finder. This will show you a package containing one or more .crash files and some metadata.
Navigate through the package until you find a crash log. You will see that the same info has or hasn't been symbolicated here.
In Xcode, open the Devices window and select a connected device, then click the View Device Logs button.
Drag the crash log in step 2 from the Finder into the list of logs for this device.
When I do this, I never see the log I added appear in the list, but if I click the headings once or twice to re-sort the list, then I see it.
After a moment, the crash log will become completely symbolicated.
If you already have a lot of logs in your list, you can compare the date, iOS version and hardware model as you view the log in the Finder to the logs in Xcode to make sure you're viewing the same log. Then look at the line that says "Triggered by Thread" to get the thread number that crashed, then scroll down to that thread to see the code that triggered the crash.
This worked for me today with Xcode 7. I hope it helps you!
When you submit apps through Xcode, an option will appear to include debug symbols. Next time you submit an app version, be sure to select that; if you did not, that might explain the problem you're seeing. Unfortunately there's no way to retroactively do that for app versions already submitted, so you'll have to wait until you're ready to submit the next version to see if that was the problem.

Unable to symbolicate crash log

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.

Resources