Develop Reference

Log to Logcat before a SIGSEGV /SEGV_MAPERR crash

I have a native library that has a native crash. The crash doesn't happen consistently and I can't reproduce it. I have access to Google breakpad's minidump and last few thousands LogCat lines from the users. The method doesn't crash all the time so I suspect perhaps it crashes because of specific param values that I haven't checked. Unfortunately this is a method that's called a lot so I can't log to LogCat all the time.
I understand that try/catch doesn't work for SIGSEGV. But is there a similar mechanism?
Something like this https://stackoverflow.com/a/2436368/4092412.

crashlytics keeps registering exception after code removed

This problem sounds really weird and it looks is somehow my mistake but isn't
I use crashlytics to keep logs and track exception of the usage of my app
for that i created a lib in the log4j interface which simple calls the crashlytics methods for log events.
On the first version of my lib i add an extra Crashlytics.logException() to every logger.error() in my code. After using it for a while i noticed that this behavior wasn't what i want and I removed the Crashlytics.logException()
BUT CRASHLYTICS KEPT SHOWING EXCEPTIONS ON THAT
I'm really confuse with that and for a long time i thought i was doing something wrong, but after debuging the code thousands of times i came to think that there is something beyond what i see
there is no metion of Crashlytics.logException() in my code, and somehow i still manage to see many errors in my crashlytics dashboard
can someone help me with that?
what events might generate a non-fatal issue on crashlytics dashboard
attach:
- https://pastebin.com/Rbu1ySpd this is the core class of my log lib
- whenever i want to log an even i do `logger.log("something");' in a very log4j way

Log.wtf vs. Unhandled Exception

I just learned about Log.wtf ("What a Terrible Failure" lol) and I'm wondering when I should use it.
What is the difference between calling Log.wtf with an exception and letting an exception go unhandled (crash)?
How does it affect crash reports in the Google Play Developer Console?
I usually throw an IllegalStateException for unexpected conditions. Should I consider calling Log.wtf instead?
Edit:
See also: Under what circumstances will Android's Log.wtf terminate my app?

What Log.wtf does is write the exception and its stack trace in the log, and only that. It neither catches nor throws exceptions. So
The difference is the exception is logged or not. The exception remains unhandled.
It doesn't affect crash reports.
If you wish to log it, go ahead. But you'll want to keep throwing IllegalStateException.
EDIT
I tried debugging and stepping into Log.wtf but no luck.
What I've found is pretty much what is answered in the linked question. It seems that in the "default terrible failure handling" Log.wtf creates an internal exception (TerribleFailure) which wraps any given exception. Then it calls RuntimeInit.wtf(). Its javadoc says:
Report a serious error in the current process. May or may not cause
the process to terminate (depends on system settings).
I guess the behavior of Log.wtf is up to the device manufacturer. My Sony C6503 doesn't seem to raise any exception or kill the process.
Some open source reference:
https://android.googlesource.com/platform/frameworks/base/+/master/core/java/android/util/Log.java
https://android.googlesource.com/platform/frameworks/base/+/master/core/java/com/android/internal/os/RuntimeInit.java

Unhandled exceptions are not logged by default. Log.wtf may or may not crash the application. If you pass an exception to Log.wtf and it crashes, then you should get a stack trace similar to what you would get if the exception were not handled. After calling Log.wtf, you should (re)throw an exception if you want to ensure a crash (without catching it of course).
There may be specific use cases for Log.wtf, but if you are unsure, it's probably better to use Log.e instead.

Can multiple data reporting utilities report on the same uncaught exception?

My app uses Flurry for analytics and the excellent ACRA for uncaught exception reporting. This means that there are 3 places uncaught exception reporting happens: Flurry, ACRA and the crash error report within the Android Developer Console. As far as I can tell, it looks like only one of the 3 areas catches and reports on an exception. And, more strangely, it seems random as to which one it is. I.e. sometimes an exception is reported in ACRA, sometimes in Flurry and sometimes in the Developer Console. I don't have a high enough volume of exceptions (thankfully!) to see any patterns, but ideally I'd like all exceptions at a minimum to go to ACRA. Am I missing something as to how this works? Is it possible for all exceptions to go to all 3 reporting places?

You can disable Flurry's exception handling using this command in your onStart() -
FlurryAgent.setCaptureUncaughtExceptions(false);
This way it won't interfere with other handlers.
Update June 2013
This answer still stands as the way to achieve this goal, but from my experience, Flurry seem to catch an exception here and there in spite of this flag. So it's not a 100% reliable solution. Recently I moved to Google Analytics, and turned off the exception handling - and it is perfectly reliable in that respect.

Need recommendation for good resource on troubleshooting android using logcat and the console [duplicate]

This question already has answers here:
Unfortunately MyApp has stopped. How can I solve this?
(23 answers)
Closed 1 year ago.
everyone. Can anyone recommend a good resource that gives insight on how to troubleshoot android using the LogCat and the Console? Any help would be much appreciated :)

I never saw anything written, but here are a few tips (or, at least, this is how I do it):
Tracing the error in the stack:
When you're troubleshooting after a force close, then always look for the ERROR part of the logcat. It will be followed by the exception type.
If you get a not-that-useful java.lang.RuntimeException, search below for the original exception thrown, e.g. Caused by: java.lang.NullPointerException
These exceptions will be followed by the stack trace of your app. You can find in there where the exception was thrown (class, method and line) and which methods called it. Try to find your package in there and figure out how it got to that exception.
If it is an exception you don't know about, google it: I usually use "java 6 xxx.xxx.xxException" or "android xxx.xxx.xxException" to quickly get the link to the API documentation about that exception.
Then read the docs about the class that is throwing the exception (e.g., which are the cases it can be null, etc.)
Customizing the logs
I abuse of the Log.d("MyClass", "Some variable =" + variable); . It ends up to be very informative. Some times I just use the log to check where in an if/else tree am I or to trace constructors (useful to know if I am reusing an object, or creating a new one some times).
If the logcat is too noisy, I use grep and a particular marker for my logs, e.g., Log.d("***> MyClass", "Some variable =" + variable); or Log.d("***> MyClass2", "onCreate()");, I filter those using a simple adb logcat | grep '\*\*\*>'
You can quickly filter for errors in the log using adb logcat *:E
When everything else fails: Post the trace here :)