Warum zeigt Android Logcat den Stack-Trace für eine Laufzeitausnahme nicht an?

Question

Eine Android-Anwendung, die ich gerade entwickle, stürzte ab (behoben das), aufgrund dessen, was eine IndexOutOfBoundsException ausgelöst haben sollte. Ich habe auf eine Zeichenfolge in der doInBackground-Methode einer Klasse zugegriffen, die die Option "AlyncTask" über den Parameter "variable arguments" (dh String ...) erweitert. Ich habe versehentlich auf den Index 1 (nicht 0) einer Variablenstring-Zeichenfolge mit einem Element zugegriffen (leicht peinlich ...). Als die Anwendung zum ersten Mal abgestürzt ist, habe ich mein logcat angeschaut (und mehrmals, um zu bestätigen, dass ich nicht verrückt war) und es gab keine Stack-Trace für eine RuntimeException. Ich stürze mein Handy ziemlich oft und es gibt immer eine nette kleine Stack-Spur, auf die ich schauen und reparieren kann, aber ich war verwirrt. Hier ist der betreffende Abschnitt meines logcat (die für eine Runtime keinen Stack-Trace enthält), nach einer Debug-Anweisung unmittelbar vor der Codezeile, die den Absturz verursacht wurde:

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() 

Und danach, eine andere Tätigkeit beginnt. Als Referenz hier ist der Code, der den Absturz verursacht:

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]; 
     //... 
    } 
    //... 
} 

Einsicht in das, was mir gefallen würde stark geschieht, da ich neugierig bin auf dem Internet wie diese nie etwas gesehen haben. Danke.

Edit: Ich habe keinen Filter

gesetzt

Answer 1

Ihre Fäden deutlich abstürzt sind (man beachte die thread exiting with uncaught exception auf zwei verschiedene Threads im selben Prozess). Der Prozess bereinigt sich selbst - Sending signal zeigt an, dass der Prozess ein fatales Signal an sich sendet. Die Frage ist also, warum Sie zwischen diesen beiden keinen Stack-Dump sehen.

Der Stapelspeicherauszug stammt aus RuntimeInit$UncaughtHandler, dem vom Framework bereitgestellten globalen nicht abgefangenen Ausnahmebehandler. Die Prozess-Selbstvernichtung findet im finally Block statt. Es ist schwierig, einen Weg zu finden, ohne das "FATAL EXCEPTION" zu protokollieren, es sei denn, etwas in Slog.e schlägt fehl und wirft.

Ich würde vermuten, dass entweder etwas in Slog.e fehlschlägt, oder jemand den uncaught Exception-Handler des Frameworks ersetzt hat. Letzteres könnte passieren, wenn Sie eine externe Bibliothek in Ihre App integriert haben, beispielsweise einen Crash-Log-Catcher oder ein Werbenetzwerk, und der neue Handler die Ausnahme nicht protokolliert, den Prozess jedoch abbricht.

Sie können es aufspüren, indem Sie einen Java-Debugger (z. B. Eclipse) anhängen. Standardmäßig stoppt es bei nicht abgefangenen Ausnahmen. Von dort aus können Sie sie verfolgen, Breakpoints setzen und Einzelschritte durch den nicht abgefangenen Exception-Handler (wenn Sie vollständige Quellen haben) und so weiter.

Answer 2

Nach Fadden der Verdacht, dass externe Bibliothek konnte uncaught Exception Handler überschreiben, ich begann zu untersuchen, alle möglichen Bibliotheken. Es stellte sich heraus, dass GoogleAnalytics Drosseln abstürzt und verhindert, dass die Stack-Trace in logcat angezeigt wird, wenn Sie enableExceptionReporting einschalten. Ich entferne diese Codezeile, dann kommt alles wieder in Fahrt !! Das könnte das erste Mal sein, dass ich so glücklich war, Unfälle zu sehen !!