15

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

Jackson Kulik
  • 308
  • 2
  • 10
  • Did you try by putting the exception code in Try Catch Block ? – Brijesh Thakur Jul 16 '13 at 17:05
  • You sure that you don't have any filter selected? – Varun Jul 16 '13 at 17:09
  • 1
    ...the problem is not that I need to prevent the code from raising the runtime exception, I already did that in another version of the code (changed the number 1 to a 0). The problem is that the old version of the code never caused a runtime exception stack trace to show up in my logcat. I want to know why that would happen. – Jackson Kulik Jul 16 '13 at 17:11
  • And I have no filter selected at all. I use command line tools for development though I am familiar with using eclipse. I simply use the command "adb logcat" and receive all logcat results unfiltered. – Jackson Kulik Jul 16 '13 at 17:13

2 Answers2

11

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.

fadden
  • 51,356
  • 5
  • 116
  • 166
  • Thank you very much. I plan on looking into it more at home, as I cannot find the time at work to. I do not have any third party libraries that should be affecting that (though I will check if Aviary, an image editor which I use as a library, does anything of the sort), and I am still seeing other stack dumps in my logcat (as it should be), so I continue to be intrigued. Thanks much for the timely and well-informed suggestions. Have a nice day. – Jackson Kulik Jul 16 '13 at 18:26
  • It's a pity the default implementation kills the process without mentioning anything about the exception being thrown. Anything to give the programmer a clue of what's going on. – smiszym Dec 31 '18 at 09:04
6

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

Arst
  • 3,098
  • 1
  • 35
  • 42