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

Question

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:

W/dalvikvm(25643): threadid=11: thread exiting with uncaught exception (group=0x40c281f8)
D/dalvikvm(25643): GC_CONCURRENT freed 1249K, 25% free 12433K/16455K, paused 2ms+6ms
W/dalvikvm(25643): threadid=15: thread exiting with uncaught exception (group=0x40c281f8)
I/Process (25643): Sending signal. PID: 25643 SIG: 9
I/ActivityManager( 5905): Process com.trade.nav.ges (pid 25643) has died.
W/ActivityManager( 5905): Force removing r: app died, no saved state
I/WindowManager( 5905): WIN DEATH: win
I/WindowManager( 5905): WIN DEATH: win
I/SurfaceFlinger( 1746): id=3848 Removed idx=2 Map Size=4
I/SurfaceFlinger( 1746): id=3848 Removed idx=-2 Map Size=4
I/WindowManager( 5905): WIN DEATH: win
I/power   ( 5905): *** acquire_dvfs_lock : lockType : 1  freq : 1000000 
D/PowerManagerService( 5905): acquireDVFSLockLocked : type : DVFS_MIN_LIMIT  frequency :  1000000  uid : 1000  pid : 5905  tag : ActivityManager
W/ActivityManager( 5905): mDVFSLock.acquire()

And after that, another activity starts. For reference, here is the code that caused the crash:

private class LoadImage extends AsyncTask<String, Integer, Bitmap> {
    String url = "";
    //...
    public LoadImage(ImageView iv, Context c) {
        //...
    }

    protected Bitmap doInBackground(String... urls) {
        // urls has one element
        url = urls[1];
        //...
    }
    //...
}

Any insight into what is happening would please me greatly, as I am curious about having never seen anything like this on the internet. Thanks.

Edit: I have no filter set

Answer 1

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.

Answer 2

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!!