Absturz ohne wirkliche Fehlermeldung

walda

walda

Enthusiast
691
Hallo!

Ich suche seit Wochen einen Fehler, der nur sehr sporadisch auftritt (sonst wär's ja fad ^^)

Ich reagiere uA auf BATTERY_CHANGED, und dort passiert es dann:
Code:
07-04 07:01:29.805 I/DrainGuardService( 5064): myLogWrite 1
07-04 07:01:29.805 I/DrainGuardService( 5064): myLogWrite 3
07-04 07:01:29.805 I/DrainGuardService( 5064): ReallyLogWrite 1
07-04 07:01:29.805 I/DrainGuardService( 5064): ReallyLogWrite 3x
07-04 07:01:29.805 I/DrainGuardService( 5064): myLogWrite 7x
07-04 07:01:29.805 D/AndroidRuntime( 5064): Shutting down VM
07-04 07:01:29.805 W/dalvikvm( 5064): threadid=1: thread exiting with uncaught exception (group=0x4001e578)

...mehr kommt nicht :(

Soll ich jetzt in jede meiner Routinen ein "Anfang" & "Ende" einbauen um zu lokalisieren was das Problem ist? Vor allem ändern sich die Battery% öfter und da geht ja alles gut.

:crying:
Danke
 
Code:
07-04 07:01:29.805 W/dalvikvm( 5064): threadid=1: thread exiting with uncaught exception (group=0x4001e578)
Mich wundert, dass da drunter kein Stacktrace kommt. Meine erste Idee wäre das hier am Anfang deines Service/Activity auszuführen und sicherzustellen, dass was gelogt wird, wenn ein Thread an einer Exception stirbt.
Code:
Thread.setDefaultUncaughtExceptionHandler(new Thread.UncaughtExceptionHandler() {
            
            @Override
            public void uncaughtException(Thread thread, Throwable ex) {
                Log.e("Tag", "Exception caught in uncaught exception handler", ex);
            }
        });
Die andere Idee ist, mit einem try-catch um den gesamten Code selber alles zu fangen und zu loggen. (Bzw. einem try-catch um den gesamten Code an allen möglichen Einsprungpunkten - bei Android dürften das schon ein paar sein.) Musste ich kürzlich auch machen als ich Module für eine bestehende Software programmiert habe, die die per Reflection lädt und hilfreicherweise alle Exceptions schluckt ohne zu loggen. Irgendwo muss die Exception sein, und in der steht drin, was los ist.
 
  • Danke
Reaktionen: walda
oder das System killt dich einfach weil dein Programm zu lange braucht um das Event abzuarbeiten.
 
Danke, ich melde mich wieder...
 
Hallo,
dank eurer Routine weiss ich nun wo es passiert, leider aber nicht warum.

Wir haben einen

PHP:
  private IntentFilter batteryLevelFilterpercentchange = new IntentFilter(Intent.ACTION_BATTERY_CHANGED);
    private BroadcastReceiver batteryLevelReceiver3;

um den Wechsel der Akku% mitzubekommen. Dies funktioniert auch in 99,9% der Fälle. Hie und da passiert halt dann das:

PHP:
07-15 12:29:41.815 D/AndroidRuntime(27028): Shutting down VM
07-15 12:29:41.815 W/dalvikvm(27028): threadid=1: thread exiting with uncaught exception (group=0x4001e578)
07-15 12:29:41.815 E/DrainGuardService(27028): Default uncaught exception handler
07-15 12:29:41.815 E/DrainGuardService(27028): Caught throwable java.lang.RuntimeException: Error receiving broadcast Intent { act=android.intent.action.BATTERY_CHANGED flg=0x60000000 (has extras) } in com.waldafx.DrainGuard.myAlarmReceiver$1@4055faa0 for thread Thread[main,5,main]

Deshalb haben wir:
PHP:
        batteryLevelReceiver3 = new BroadcastReceiver() {        	
            public void onReceive(Context context, Intent intent) {
            	int level = -1;
            	try 
            	{
	                int rawlevel = intent.getIntExtra(BatteryManager.EXTRA_LEVEL, -1);
	                int scale = intent.getIntExtra(BatteryManager.EXTRA_SCALE, -1);	                
	                if (rawlevel >= 0 && scale > 0) {
	                    level = (rawlevel * 100) / scale;
	                }
...
mit einem try-finally abgesichert, aber so weit kommt er gar nicht. Wie kann man dieses "Error receiving broadcast Intent" absichern? Die Nachricht kommt ja vom System und wir können ja nix dafür, dass der Intent nicht ordentlich befüllt zu sein scheint.

Danke :)
 

Ähnliche Themen

A
Antworten
2
Aufrufe
779
Arti851
A
A
Antworten
1
Aufrufe
715
swa00
swa00
S
Antworten
15
Aufrufe
1.508
shareking
S
Zurück
Oben Unten