I'm looking for logs of the Xcode application itself. Not logs of my iOS app or device.
I've been doing a bit of experimental work with the storyboard source code xml. Sometimes I'll get a random crash of Xcode or a message like "The document Main.storyboard' could not be opened. Could not verify document content" (This is not git conflict related)
I'd like to look in the logs to see if it gives a clue as to what part of the xml is causing these crashes or errors.
Note: I was able to find some additional crash information by looking in the 'console' app. But not error information.
Thanks.
There are a few things here. First of all, I do not believe Xcode writes any dedicated log files (as opposed to, say, Android Studio, that puts logs under ~/Library/Logs/AndroidStudio2.2). Having said that, there are a couple of places to get them:
1. The device logs
Xcode uses system logging to log its messages to the console. If you open the Console app, find your macOS device in the Devices list and look at the messages. By default, it shows all the messages from all the apps, but you can filter our by PROCESS - Xcode (filtering is a bit unintuitive, you first search for Xcode which generates ANY|Xcode filter, than you select ANY and change it to PROCESS).
The one problem with the Console app on macOS Sierra is that it only shows logs from when you started the Console app, not earlier. You can use the log command line to collect previous logs (e.g. sudo log collect --last 1d). You can find more information about it here.
Alternatively, you can actually start Xcode from the terminal (by typing /Applications/Xcode-beta.app/Contents/MacOS/Xcode in the terminal window). If you do that, all the logs will be written to the terminal console.
2. The Diagnostic Reports
These (also accessible via the Console app) will contain crashes that Xcode itself doesn't log (there are some cases where Xcode will die silently, but the Diagnostics Reports may still contain the error along with the callstack and other useful info). Note that there are two places where Diagnostic Reports are stored, under ~/Library/Logs and /Library/Logs - make sure to check both.
Related
I'm using crashlytics for crash reporting.
In the last release I'm seeing a lot of dsym missing warnings. I have tried to upload the dsym manually with no luck.
Questions
Is the number of crashes affected by missing dsym?
Is number
of crash-free users and crash-free sessions affected by missing
dsym?
I'm trying to decide whether I should pause my releases until I troubleshoot this, or whether the stability report is accurate even though the dsym is missing
Here is the answer I got from Fabric Support
Thanks for reaching out. Crashes with missing dSYMS will not be counted in the number of crashes reported by an app. This will also affect your crash-free users and crash-free session percentage"
Yes, you'll still get crash reports without dsyms they'll just live in this "unsymbolicated crash" page. EDIT: according to fabric customer service (accepted answer) these crashes will also not count towards the crash-free %s
A side note: But for symbolicated crashes, one of the interesting things about Fabric is that the crash count will always be "accurate", but you won't actually get the crash report itself until the next time the user opens your app and its able to send to the server. So it's common for the overview you see on Latest Release or the home page to say XXX crashes, but when you actually click into the release itself you don't see nearly as many. It just means that the user crashed and Crashlytics was able to log the crash itself, but not send the crash logs yet.
Side note but if you want to make sure you're getting dSYM generated you should go Build Settings > Build Options > Debug Information Format, and make sure DWARF with dSYM is enabled. The run script Fabric makes you add makes sure it's automatically sent
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.
How can I do to see the log of the crash in Xcode?, because when I have active the crittercism, with debugger mode, can not see the console log, always if I want to use xcode debugger, I need to disable crittercism and I think that is wrong.
Crittercism is right, it sends the report to the web service when open the app, but if I have the device connect to xcode, I can not see in the reports of the crash and crittercism does not send it to the web it.
I do not know if something is missing, exist something like a line that I need to add for this start to work ?
I've used Crittercism extensively for iOS and Android.
You should be able to see your Crash Logs in both Xcode as well as
within the Crittercism platform when your device is connected to Xcode.
Also, be sure you've configured your app for automatic symbolication.
see this article.
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.
I am getting the following crash reports from some recent apps deployed to the app store. I am not sure what is causing it or how to fix it.
Could not load 'monotouch' for registration. This could be due to an
outdated assembly kept by the simulator, location:
/private/var/mobile/Applications/1BEDC27F-B313-4240-8490-EAD680F8E78A/PhotoTour.app/monotouch.dll
It refers to the Simulator in the error, but the app from the app store.
The message itself refers to a condition that was known to exists only in the simulator. The iOS Simulator does not remove old files (it only updates them).
In recent MonoTouch versions there's another fix now that should prevent even this message to occur (on simulator builds). It's very unlikely that the same condition (stale binaries) is occuring on devices.
The exception behind the error means that that the types inside the assembly (monotouch.dll) could not be registered properly. This should not happen, even less randomly (i.e. if it occurs it should be systematically on every execution and on every device, including when testing). Since registration occurs everytime at startup it's hard to see why testing (and Apple app approval) has not catched this.
Please fill a bug report including the exact version of MonoTouch being used and attach a log of the (release) build (add -v -v -v so we'll get more details about the build). Also attach the logs from where you gathered the above message - other lines of the same logs might gives us some clues.