An android application that I am currently developing was crashing (fixed that), due to what should have raised an IndexOutOfBoundsException. I was accessing a string in the doI
As per fadden's suspect that external library could override uncaught exception handler, I started to investigate any possible libs. Turned out that GoogleAnalytics
throttles crashes and prevents the stack trace from being displayed in logcat if you turn on enableExceptionReporting
. I remove this line of code then everything gets back on track!! That could be the first time I was so happy to see crashes!!
Your threads are clearly crashing (note the thread exiting with uncaught exception
on two different threads in the same process). The process is cleaning up after itself -- Sending signal
indicates the process is sending a fatal signal to itself. So the question is why you aren't seeing a stack dump between these two.
The stack dump comes from RuntimeInit$UncaughtHandler, which is the framework-provided global uncaught exception handler. The process self-annihilation happens in the finally
block. It's hard to see a way to get out of this without logging "FATAL EXCEPTION", unless something in Slog.e
fails and throws.
I would guess that either something is failing in Slog.e
, or somebody has replaced the framework's uncaught exception handler. The latter could happen if you've incorporated some external library into your app, such as a crash log catcher or an ad network, and the new handler doesn't log the exception but does kill the process.
You can track it down by attaching a Java-language debugger (e.g. Eclipse). By default it will stop on uncaught exceptions. From there you can trace it around, set breakpoints and single-step through the uncaught exception handler (if you have full sources), and so on.