I'm trying to log a time before the app gets terminated and it seems to behave differently on an app crash so the time never gets logged. NSSetUncaughtExceptionHandler is a potential solution but I'm finding that it's not recommended if we're already using other 3rd party frameworks like crashlytics / fabric. Can anyone suggest the proper approach to solving this problem?
Related
I am a new iOS developer, and I was attempting to implement NewRelic as my crash reporting platform for a test application before I use it with a different application, but I cannot seem to receive any data on NewRelic. I went through the Cocoapods installation here: https://docs.newrelic.com/docs/mobile-monitoring/new-relic-mobile-ios/installation/cocoapods-installation/ with my own app on Swift. After that didn't work, I used a coworkers test app, who had the crash reporting working, and it still wouldn't work for me.
One difference that we have noticed is that I receive this notification from Apple when crashing my test app on XCode simulator...
We figure the data isn't being sent because something is getting in the way of the process, but we can't figure out why. I have tried disabling debugging on XCode. I have tried almost everything that NewRelic suggests on their website and through their technical support. Has this happened to anyone else before?
With a custom crash reporting system (like the ones specialized at Ask the user to send crash log after crash on iPhone) to send the log, the app needs to restart. Why? Isn't there a possibility to send it during the custom exception handling? Or is there a crash reporting system that doesn't need to restart the app?
When a crash occurs the app is in a highly unstable state. So a crash reporting library can not do anything since even allocating memory at crash time may cause way more damage. So crash reporting SDKs can only use so-call async-safe C methods to collect all crash data. Any Objective-C code can not be processed either and also the iOS networking stack can not be used.
Please also note that exceptions are just one example of app crashes in Objective-C, there are also crashes triggered by low-level BSD signals. Both types mean that the app is in a highly unsafe and unstable state and as little code as possible should be invoked at crash time.
So this would require a rewrite of most of the networking frameworks to be able to send data out at crash time, and this may even not be possible to do in a safe way. That is why all proper crash reporting SDKs don't do anything like that.
In addition, on iOS it is not possible to create another process which could send the data in the background, so the only safe and possible solution is to send data the next time the app starts.
Now this has another conclusion that crashes that happen early on app startup might never be sent since the app is crashing before or while it sends. Some SDKs provide mechanisms to handle that scenario which most likely requires changes in your app startup code.
Since you app crashed there is no process running any more that you app controls, thus you can not start a new process to send the report.
Any code in the crash handler only has limited time to save what ever made you app crash before iOS kill whole app and removes it from memory.
When you restart you app the crash reporter formats the crash report and sends it. This can only be down when the when you app is active.
Currently, I am using Crittercism for crash reporting and making sure that I add dSYMs to get symbolicated crash reports.
But it is not helping with some of my crashes which are segmentation faults (SIGSEGV and SIGBUS). They occur randomly and I haven't been able to reproduce them on device and on simulator. I have tried to find a pattern by trying my app on different ios devices with different network connections (3G, Wifi, Edge) but with no success.
What can be my next step?
Not much to go on, but here are a few places to look:
If you have multiple threads, check to make sure they are behaving properly. Make sure you synchronize properly if multiple threads could be accessing the same objects.
Check your NSNotifications - could one be posted when you are not expecting it?
I have found that the hardest bugs to find are those that are caused by asynchronous events - either in other threads or due to external events that you might be monitoring.
Not being able to reproduce the bug in your development environment will make it very hard to find.
That probably sounds a lot worse than it is, but here's my question.
I am dealing with a crash on an actual device, that one of my tester's is using. At the moment, there is no way to discover what is causing the crash. I can not reproduce it on the simulator. However, on the simulator when something crashes I get log info about it in the output window. But I don't want to keep testing with the device connected.
Is it possible to log crash exceptions, etc into a file when things crash. I know certain apps can do it, but I am not sure how?
Any info would be appreciated.
There are generally two ways to do that:
Someone get the tester to send you the crash reports, that iOS created on the device. This is usually too tricky for end users, so the next suggestion works better. That's also why I am not describing how to do that :) But you'll find plenty of documentations on that process.
Integrate a crash reporting library, that catches the crashes and allows you to receive them in various ways. You should not implement your own global crash exception handler, things are just too complex to do it right (even though other people will tell you otherwise). Also crashes caused by exceptions are only one type of crashes.
There are multiple open source libraries out there, the safest one to use is anything based on PLCrashReporter. Most others use private or undocumented iOS APIs, or are not async-safe, which basically means those can destroy app data or make the crash even worse. See this blog post about the topic: http://landonf.bikemonkey.org/code/crashreporting/Reliable_Crash_Reporting_1.1.20130119.html
The following linked answer shows some of the available options on how to add logging to your app and also various options on how to receive crash reports for test version and also once the app is released: Including custom data into iOS crash dumps
If you're open to using a third party service, I use https://www.crashlytics.com. Makes debugging crashes from user devices painless.
I've got a Cordova/PhoneGap + JQueryMobile application running on iOS and a few customers are reporting that the app is just "vanishing" on them during certain interaction points.
Unfortunately I'm not able to reproduce it, so I'm kind of stuck. I'm wagering that the app is running out of memory or maybe hitting some other kind of iOS level exception.
What I'm wondering is this - does anyone have any suggestions on a good way to capture native exceptions in PhoneGap and either log them or trigger a crash report that the user can email to us? Until we can see what the crash is being triggered by, there is no hope of fixing it.