Will failed assert statements generate crash reports (with stack traces) that'll wind their way through iTunes Connect?
I'd like to know the same thing for NSAssert as well as uncaught C++/Obj-C exceptions.
Please note that I'm using assertions for internal consistency and logic errors, not for things like file errors.
If they don't generate error reports, is there a way to make them (with custom macros, exception handlers, etc)? It's important that I be able to obtain a stack trace.
Xcode will, by default, disable NSAssert() macros for release builds if you are using one of the standard Xcode templates. Alternately, you can disable them yourself by adding an NS_BLOCK_ASSERTIONS flag to Other C++ Flags in your Build Settings.
Yes, uncaught exceptions will generate a crash report - I'm looking at one from the iTunes Connect crash reporter right now! Basically, almost anything that causes your application to crash and save logs will send reports back to Apple.
That said, if you're worried about it you may want to implement your own handler for crash reporting, because a) only users who opt to share diagnostic information with Apple will send crash reports back to iTunes Connct, and b) there is no guarantee that even then a crash report will make it back to you for review.
You can either do this yourself using uncaught exception handlers, through an existing analytics package (Flurry supports this), or use an open source library which are of variable quality (here's one I've found online - I implement my own code for my reporting, so your mileage may vary!)
Related
I'm getting this super obnoxious output printed out thousands of times slowing down my program:
2021-11-08 12:37:57.183588-0800 (myScheme)[27459:701276] [boringssl] boringssl_metrics_log_metric_block_invoke(144) Failed to log metrics
In StackOverflow, I'm only finding that it is related to an XCode bug and there isn't much that can be done about it. However, I'd like to experiment with alternative pieces of code that might be able to perform whatever task is being run but without triggering this stupid issue.
Is there a way I can set a breakpoint for this so I can study the stack trace which leads to it?
Thanks
A few observations:
This output is a simple logging statement (such as generated by OSLog or Logger) in a framework. You generally cannot control what logging these frameworks do, so don’t worry about it.
In terms of slowing down your app, the logging system is exceptionally efficient, depending upon the level of the individual logging message, so I wager that debugging messages are not slowing down your app (observably). There are different logging levels, i.e., “debug”, “info”, “notice”, “error”, and “fault”, each with its own performance characteristics. See WWDC 2020 Exploring logging in Swift. In particular, “debug” logging messages are highly performant.
The real issue is how to filter your debugger console so your salient logging statements don’t get lost in all the cruft from logging statements from all the frameworks you might be using (such as “boringssl”).
I find that filtering the console is extremely useful. Unfortunately, The Xcode console filter does not offer regex or “negative” filters (i.e., you cannot say “show me everything except boringssl messages”). But you can tell it to show you your particular logging statements.
In particular, you might consider using Logger (or OSLog for older targets), instead of print, for your logging statements:
import os
private let logger = Logger(subsystem: Bundle.main.bundleIdentifier!, category: "AppDelegate") // use whatever category you want; I personally use a separate logger for each compilation unit and make the “category” the name of that unit
And later, in lieu of print, use Logger:
logger.debug(...)
(In older targets, you can use OSLog; the syntax is slightly different, but the idea is the same.)
Anyway, when I then look at my unfiltered log, I’ll see all the cruft, where it is hard to see the messages I care about:
But I can focus on my salient events, in this case by filtering on “[AppDele” for log messages from my AppDelegate:
This logging pattern also allows you to watch iOS logging messages emitted by a device on one’s macOS Console, which is critical when diagnosing issues that only manifest themselves when not attached to a debugger. This is illustrated in that WWDC video.
In short, do not worry about framework logging messages, but just have a workflow that lets you easily focus on the console messages that matter.
I recently upgraded an application from .net 3.5 to 4.0. Since I did that, with debug settings to break on all exceptions enabled, I've been getting a few of these exceptions each time I start a section of the application that connects to a database using the EF. The exact number is variable; sometimes I only get one, others several in rapid succession.
ReleaseHandleFailed was detected Message: A SafeHandle or
CriticalHandle of type
'Microsoft.Win32.SafeHandles.SafeCapiHashHandle' failed to properly
release the handle with value 0x06AD3D08. This usually indicates that
the handle was released incorrectly via another means (such as
extracting the handle using DangerousGetHandle and closing it directly
or building another SafeHandle around it.)
I never got exceptions like this when targeting 3.5. These exceptions don't have any meaningful call stack attached, all I get is [External Code], denying any easy way to localize where they're coming from. The reason I suspect EntityFramework is somehow involved is that one section of the app uses nHiberate instead doesn't generate any of these messages.
To run down other dependencies that might be involved: In all cases, the ORM is talking to an Sql Compact database MS Sync Framework 2.1 is being used to update the local DB from SqlServer. The Entity framework models have been regenerated with the 4.0 framework, and I upgraded the cache DB to v4.0 as well.
Since there's no call stack I'm not sure if these messages fall into the category of "harmless" errors automatically cleaned up internal to the framework; or if there's an exception eater catching them elsewhere in the application.
This is not an exception, it is a Managed Debugging Assistant warning. You might have gone over-board a bit when you changed the settings to "break on all exceptions enabled". Debug + Exceptions, Managed Debugging Assistants node, untick the "ReleaseHandleFailed" warning. It is off by default.
The MDA catches an old bug that's gone undetected for a while in the AesCryptoServiceProvider class. Backgrounder is here.
Judging from your comment, you are about to make a drastic mistake. You do not solve this by avoiding encryption or compromising your dbase connection security. You accidentally turned on an MDA that's normally off. MDAs in general tend to produce false warnings and many of them are turned off by default. The warning is in fact bogus, releasing the handle failed because it was already released. This happens in the finalizer thread, that's why you don't get a stack trace. And thus can't easily find out what code uses the class in the first place.
The proper way to fix it is to use the Debug + Exceptions dialog properly. Fix the problem you created by clicking the Reset All button. Then click only the Thrown checkbox for Common Language Runtime exceptions. That's what you are trying to debug.
i used Bugsense framework in iPhone application to get the crashe logs, and it works fine.
but when i get the crash report from iTunes account, the crash report indicate that there is a crash in bugSense framework.
What this is mean? is it indicate that crashes in applications reported by bugSense ? or it is actual crash in the framework itself?
Please Help.
Thx
It could be, that this is a crash in their SDK. Sadly they perform non-async safe functions in their framework once the crash happened. See http://landonf.bikemonkey.org/code/objc/Reliable_Crash_Reporting.20110912.html for more details on what that means (in this case calling Objective-C code once a crash occurred is unsafe). You might want to contact them to make the fix this possible problem.
But the messages lower in the stack trace also indicate, that this is a crash that happened because of an uncaught exception occurred, which would normally cause another Last Exception Backtrace to appear on top of Thread 0. I am not sure if they have that functionality included. If they do, this causes that block only appear in their own crash report but not in the crash reports iOS creates. Then this is nothing to worry about, except that code above being bad as already mentioned.
If you have enabled immediate dispatch in BugSense, this is probably the reason of this crash, as it isn't guaranteed to be safe.
For more info you can check this: https://github.com/bugsense/plcrashreporter-bugsense/wiki/Using-the-BugSense-2.x-iOS-library , section Enabling immediate dispatch
this may happen when there is no internet connection, try enable immediate dispatch in bug sense
Is there a way to include an error description string in a crash report? I'm talking about crash reports that are sent via iTunes Connect. It would be nice if I could log the reason for a crash.
This question asks about including console output, but I'd be happy just to able to include an error description string, without resorting to a 3rd party library.
EDIT:
There are errors I can detect where it's unwise or impossible to attempt to recover, because the program is probably in a corrupt state. I'd rather not catch these exceptions so that I get automatic error reporting with a stack trace. Sometimes, there is extra information that I'd like to log (that cannot be deduced from the stack trace), such as the current state of a state machine.
How about a third party crash reporter? I've integrated QuincyKit, and even found a way to annotate them.
Also, when the app actively begs for the crash report to be sent to the support, you get much more of them. The things you learn...
I've searched and searched. There seems to no way to annotate a pending crash report. If someone comes up with an answer, I'll change the accepted answer.
I trying to write a a crash report feature that when you launch the app after a crash, it will offer to send the crash report to the server. I can't find how to get the crash log within the app. I saw there is a framework that doing so (PLCrashReporter), however this framework is large and I don't need most of it's features.
Does anyone knows how to simply access the log?
Thanks,
Guy.
I guess I don't have the karma to add a comment to Nimrod Gat's answer, so I have to provide my follow-up here. I'll try to make it worthy of a standalone answer.
It's very, very difficult to write a safe, correct, and reliable crash reporter, especially one that runs directly in-process. The code referenced in Nimrod Gat's answer is not correct and honestly, that blog post should be retracted. Signal handlers must only run async-safe code, and that code isn't async-safe:
http://www.cocoadev.com/index.pl?SignalSafety
Crash handling is even more complicated than normal signal handling, because that you can't expect the process to continue to run successfully after your signal handler returns.
It's tempting to think you can just hack together a simpler solution, and it will work some of the time, but there's a good reason people like Google's engineers have thousands of LoC dedicated to reliable crash reporting:
http://code.google.com/p/google-breakpad/
On iOS, you should just use PLCrashReporter. On other platforms (such as Mac OS X) you should use Google Breakpad. There's no point in re-inventing this wheel unless you're going to do it not only correctly, but better than what already exists.
I had this similar issue and the PLCrashReported seemed too complicated for what I wanted to do.
Note that you can't access the crash report generated by Apple, the PLCrashReport generates it's own reports and store them in the user's cache folder.
Eventually, I used the following example:
http://cocoawithlove.com/2010/05/handling-unhandled-exceptions-and.html
it's very simple and easy to use, just register exception and signal handlers using:
NSSetUncaughtExceptionHandler(&HandleException);
signal(SIGABRT, SignalHandler);
signal(SIGILL, SignalHandler);
signal(SIGSEGV, SignalHandler);
signal(SIGFPE, SignalHandler);
signal(SIGBUS, SignalHandler);
signal(SIGPIPE, SignalHandler);
and get the stack trace using the backtrace method in UncaughtExceptionHandler class.
Maybe a better solution will be to use a fully specialized end-2-end solution/service? Such as http://apphance.com. It is currently in closed beta testing phase, but you can ask for participation and we'll get back to you pretty quickly. The only thing you need to do is to register for an API key and embed a small framework library into your app (or .jar file in android). Then you have remote access not only to crashlogs but also to a debug logs generated by the application - which makes it much more useful. It is for now targeted to be used during testing, but there will soon be a lite version that you will be able to embed into app-store-released application.
Inside the framework we are doing all the magic of plugging-into the apple's framework and getting the crashlog information, decoding stack traces, even handling out-of-memory cases. All the comments by #nupark hold very much true: We spend countless hours on making it works seamlessly - thread-safeness, making sure that we can do the job of saving everything within the time required by Apple's framework before your app get finally killed, getting stack trace from out-of-memory case (that one was really difficult). The same for android - we've done some clever tricks there to make sure it's really working fine.
Disclaimer: I am CTO of Polidea, company which is behind apphance and co-creator of the solution.
There are a bunch of (SAAS) E2E solutions that you may be very happy to know.
Very very simple to integrate into your application
Have Fun...
crashlytics (Free and my preferred)
hockeyapp
bugSense
Crittercism
In our days you may use the built-in crash reports (iOS & Android)
iOS (Itunes connect) - Viewing Crash Reports
Understanding Crash Reports
on iPhone OS
Reading Android Market Crash Reports