Why does android logcat not show the stack trace for a runtime exception?

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 doInBackground method of a class that extends AyncTask, from the variable arguments parameter (ie String...). I was accidentally accessing index 1 (not 0) of a one element variable argument string (mildly embarrassing...). When the application first crashed I looked at my logcat, (and many times again to confirm that I wasn't insane) and there was no stack trace for a RuntimeException to be found. I crash my phone quite often and there is always a nice little stack trace for me to look at and fix with, but I was puzzled by this. Here is the pertinent section of my logcat (which contains no stack trace for a runtimeexception), following a debug statement right before the line of code that was causing the crash:

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.