问题
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
回答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.
回答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!!
来源:https://stackoverflow.com/questions/17682336/why-does-android-logcat-not-show-the-stack-trace-for-a-runtime-exception