Native Absturz ("memory violation", sig = 11) anstelle von Android Stack-Trace

Question

Ich habe vor kurzem mehr Abstürze in meiner App gesehen, in Situationen, in denen ich einen verwalteten Absturz und ein Android sehen sollte Stapelverfolgung. Bei einem systemeigenen Absturz wird die App sofort geschlossen, ohne dass das Feld "Leider wurde Ihr_App_name gestoppt" angezeigt wird. Und statt eines netten Android-Stack-Trace in logcat, ich sehe etwas wie folgt aus:

04-01 16:07:53.165 1263-1263/? E/audit: type=1701 msg=audit(1459544873.165:4214): auid=4294967295 uid=10535 gid=10535 ses=4294967295 subj=u:r:untrusted_app:s0 pid=2372 comm="app.debug" reason="memory violation" sig=11 

Um dies zu testen, habe ich erzeugt absichtlich eine Nullpointer mit dem folgenden Code innerhalb der onClick() -Methode eines OnClickListener:

Log.v("debugtag", "" + ((String)null).length()); 

Ich wusste sicher, dass dies zu einem Android-Stack-Trace führen sollte, aber stattdessen sah ich nur die Ausgabe mit einem nativen Absturz verbunden. Etwas stört eindeutig die Ausnahmebehandlung.

Ich bemerkte, dass dies nach einem Upgrade auf Flurry 6.3.0 begann. Hat sonst noch jemand das gesehen?

Answer 1

Ich Downgrade auf Flurry 6.2.0, und dieses Problem ging weg. Anstelle von nativen Abstürzen sehe ich nun wie erwartet volle Android-Stack-Traces.

Beim Debuggen einer App mit Flurry 6.3.0 bemerkte ich, dass ich manchmal kurz vor dem systemeigenen Absturz in Flurrys uncaughtException() -Methode endete. Der dekompilierte Flurry-Code ist deutlich verschleiert. Innerhalb der Klasse "ma" gibt es eine private innere Klasse "a", die UncaughtExceptionHandler implementiert. Im uncaughtException() -Methode der inneren Klasse „a“, das ist, was ich als die ersten vier Zeilen Code zu sehen:

ma var3 = ma.this; 
Throwable var8 = var2; 
Thread var7 = var1; 
Set var9 = var3.c(); 

in die letzte Zeile des Codes ausgeführt wird, die Debug-Sitzung beendet und der native Absturz .

Ich habe diese Situation Flurry gemeldet. Ich weiß noch nicht, ob das etwas ist, was meiner App eigen ist, oder ob dies ein Problem mit Flurry ist. Ich werde hier aktualisieren, sobald zusätzliche Informationen verfügbar sind.

I tat versuchen, FlurryAgent.setCaptureUncaughtExceptions(false) vor Aufruf von FlurryAgent.init() aufzurufen, aber der native Absturz tritt immer noch auf.

UPDATE: Flurry meldet das in ihrer Version 6.3.1 behobene Problem. Laut ihrer release notes hat das in 6.3.0 eingeführte Problem nur Debug-Builds betroffen - nicht Release-Builds.

Answer 2

Das gleiche hier. Um dieses Problem zu beheben, müssen Sie auf 6.2.0 herunterstufen.