kandi X-RAY | CrashEye Summary
kandi X-RAY | CrashEye Summary
CrashEye is an ios crash monitor，automatic catch exception crash & signal crash and return the stacktrace.
Top functions reviewed by kandi - BETA
CrashEye Key Features
Trending Discussions on CrashEye
I would like to catch all exceptions that are occurring in iOS app and log them to file and eventually send them to back-end server used by the app.
I've been reading about this topic and found usage of signals sent by device and handling them, but I'm not sure if it's gonna break App Store Review guidelines or it may introduce additional issues.
I've added following to
ANSWERAnswered 2019-Feb-12 at 15:27
former Crashlytics iOS SDK maintainer here.
The code you've written above does have a number of technical issues.
The first is there are actually very few functions that are defined as safe to invoke inside a signal handler.
man sigaction lists them. The code you've written is not signal-safe and will deadlock from time to time. It all will depend on what the crashed thread is doing at the time.
The second is you are attempting to just exit the program after your handler. You have to keep in mind that signals/exception handlers are process-wide resources, and you might not be the only one using them. You have to save pre-existing handlers and then restore them after handling. Otherwise, you can negatively affect other systems the app might be using. As you've currently written this, even Apple's own crash reporter will not be invoked. But, perhaps you want this behavior.
Third, you aren't capturing all threads stacks. This is critical information for a crash report, but adds a lot of complexity.
Fourth, signals actually aren't the lowest level error system. Not to be confused with run time exceptions (ie
NSException) mach exceptions are the underlying mechanism used to implement signals on iOS. They are a much more robust system, but are also far more complex. Signals have a bunch of pitfalls and limitations that mach exceptions get around.
These are just the issues that come to me off the top of my head. Crash reporting is tricky business. But, I don't want you to think it's magic, of course it's not. You can build a system that works.
One thing I do want to point out, is that crash reporters give you no feedback on failure. So, you might build something that works 25% of the time, and because you are only seeing valid reports, you think "hey, this works great!". Crashlytics had to put in effort over many years to identify the causes of failure and try to mitigate them. If this is all interesting to you, you can check out a talk I did about the Crashlytics system.
So, what would happen if you ship this code? Well, sometimes you'll get useful reports. Sometimes, your crash handling code will itself crash, which will cause an infinite loop. Sometimes your code will deadlock, and effectively hang your app.
Apple has made
exit public API (for better or worse), so you are absolutely within the rules to use it.
I would recommend continuing down this road for learning purposes only. If you have a real app that you care about, I think it would be more responsible to integrate an existing open-source reporting system and point it to a backend server that you control. No 3rd parties, but also no need to worry about doing more harm than good.
No vulnerabilities reported
Reuse Trending Solutions
Subscribe to our newsletter for trending solutions and developer bootcamps
Share this Page