Android-dalvik-garbage-collection kann Abstürzen?
Arbeiten wir an einem Projekt für Android jelly bean. Unsere Plattform ist arm-basiert, und die kernel-version 3.1.10. In unserem Entwicklungsprozess haben wir festgestellt, dass es eine sehr geringe Wahrscheinlichkeit, dass der Absturz geschah in dalvik. Auf der Grundlage der folgenden Ablaufverfolgung Protokoll, der Absturz erschien während der garbage collection-Funktion. Nach der Verwendung addr2line zu analysieren, die pc-Adresse, wir fanden die obj->clazz wurde ein gegen-Adresse, wenn das Problem passiert ist.
Die code flow:
(dvmHeapScanMarkedObjects -> processMarkStack-> scanObject->(IS_CLASS_FLAG_SET(obj->clazz,CLASS_ISARRAY)))
Nun sind wir hier hängengeblieben und kann nicht einen Weg finden, es zu lösen. Wir brauchen also mehr Anregung und Hilfe.
Kennt jemand dieses Problem oder wie schaut es an?
Die backtrace-log wie folgt:
F/libc ( 912): Fatal signal 11 (SIGSEGV) at 0x00000025 (code=1), thread 912 (zygote)
I/DEBUG ( 910): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***I/DEBUG ( 910): Revision: '32'
I/DEBUG ( 910): pid: 912, tid: 912, name: zygote >>> zygote <<<
I/DEBUG ( 910): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000025
I/DEBUG ( 910): r0 00000005 r1 41246df0 r2 44208890 r3 412471e8
I/DEBUG ( 910): r4 40e3c1b8 r5 412569c0 r6 40e3c1b8 r7 41246df0
I/DEBUG ( 910): r8 0000154c r9 00000000 sl 000798e4 fp 7fffffff
I/DEBUG ( 910): ip 51b2c044 sp bee580c0 lr 40dc5b88 pc 40dc598c cpsr 80000010
I/DEBUG ( 910): d0 6e69737275636567 d1 6f7268540000fa2e
I/DEBUG ( 910): d2 573752085737512e d3 573752785737522e
I/DEBUG ( 910): d4 5737527857375240 d5 573841a0573752b0
I/DEBUG ( 910): d6 00010000573841d8 d7 000000614ac3ff00
I/DEBUG ( 910): d8 0000000000000000 d9 0000000000000000
I/DEBUG ( 910): d10 0000000000000000 d11 0000000000000000
I/DEBUG ( 910): d12 0000000000000000 d13 0000000000000000
I/DEBUG ( 910): d14 0000000000000000 d15 0000000000000000
I/DEBUG ( 910): d16 0000000000019a5c d17 0000000000019a5c
I/DEBUG ( 910): d18 0000000000000000 d19 3fe8000000000000
I/DEBUG ( 910): d20 0000000000000000 d21 0000000000000000
I/DEBUG ( 910): d22 0000000000000000 d23 0000000000000000
I/DEBUG ( 910): d24 0000000000000000 d25 0000000000000000
I/DEBUG ( 910): d26 0000000000000000 d27 0000000000000000
I/DEBUG ( 910): d28 0000000000000000 d29 0000000000000000
I/DEBUG ( 910): d30 0000000000000000 d31 0000000000000000
I/DEBUG ( 910): scr 60000010
I/DEBUG ( 910):
I/DEBUG ( 910): backtrace:
I/DEBUG ( 910): #00 pc 0003798c /system/lib/libdvm.so
I/DEBUG ( 910): #01 pc 00037b84 /system/lib/libdvm.so
I/DEBUG ( 910): #02 pc 000298c0 /system/lib/libdvm.so (dvmCollectGarbageInternal(GcSpec const*)+196)
I/DEBUG ( 910): #03 pc 0002a0bc /system/lib/libdvm.so (dvmMalloc(unsigned int, int)+152)
I/DEBUG ( 910): #04 pc 00054f57 /system/lib/libdvm.so (dvmAllocObject+6)
I/DEBUG ( 910): #05 pc 0001ecb0 /system/lib/libdvm.so
I/DEBUG ( 910): #06 pc 0002b754 /system/lib/libdvm.so (dvmInterpret(Thread*, Method const*, JValue*)+184)
I/DEBUG ( 910): #07 pc 0005fe09 /system/lib/libdvm.so (dvmCallMethodV(Thread*, Method const*, Object*, bool, JValue*, std::__va_list)+272)
I/DEBUG ( 910): #08 pc 0005fe33 /system/lib/libdvm.so (dvmCallMethod(Thread*, Method const*, Object*, JValue*, ...)+20)
I/DEBUG ( 910): #09 pc 000539c9 /system/lib/libdvm.so (dvmPrepMainThread()+188)
I/DEBUG ( 910): #10 pc 00047c65 /system/lib/libdvm.so (dvmStartup(int, char const* const*, bool, _JNIEnv*)+1108)
I/DEBUG ( 910): #11 pc 0004dd8d /system/lib/libdvm.so (JNI_CreateJavaVM+544)
I/DEBUG ( 910): #12 pc 00047227 /system/lib/libandroid_runtime.so (android::AndroidRuntime::startVm(_JavaVM**, _JNIEnv**)+1626)
I/DEBUG ( 910): #13 pc 000476bd /system/lib/libandroid_runtime.so (android::AndroidRuntime::start(char const*, char const*)+176)
I/DEBUG ( 910): #14 pc 00000db7 /system/bin/app_process
I/DEBUG ( 910):
I/DEBUG ( 910): stack:
I/DEBUG ( 910): bee58080 00000000
I/DEBUG ( 910): bee58084 40dc599c /system/lib/libdvm.so
I/DEBUG ( 910): bee58088 41247f38 /dev/ashmem/dalvik-heap (deleted)
I/DEBUG ( 910): bee5808c 000003f0
I/DEBUG ( 910): bee58090 000000fd
I/DEBUG ( 910): bee58094 00000000
I/DEBUG ( 910): bee58098 41246ebc [heap]
I/DEBUG ( 910): bee5809c 40db7578 /system/lib/libdvm.so (dvmHeapBitmapScanWalk(HeapBitmap*, void (*)(Object*, void*, void*), void*)+128)
I/DEBUG ( 910): bee580a0 40dc5b9c /system/lib/libdvm.so
I/DEBUG ( 910): bee580a4 41247f38 /dev/ashmem/dalvik-heap (deleted)
I/DEBUG ( 910): bee580a8 40e3c1b8 /system/lib/libdvm.so
I/DEBUG ( 910): bee580ac 412569a0 /dev/ashmem/dalvik-heap (deleted)
I/DEBUG ( 910): bee580b0 40e3c1b8 /system/lib/libdvm.so
I/DEBUG ( 910): bee580b4 41246df0 [heap]
I/DEBUG ( 910): bee580b8 df0027ad
I/DEBUG ( 910): bee580bc 00000000
I/DEBUG ( 910): #00 bee580c0 51b2c048 /dev/ashmem/dalvik-mark-stack (deleted)
I/DEBUG ( 910): bee580c4 41246df0 [heap]
I/DEBUG ( 910): bee580c8 41246dd8 [heap]
I/DEBUG ( 910): bee580cc 40e3c1b8 /system/lib/libdvm.so
I/DEBUG ( 910): bee580d0 00000001
I/DEBUG ( 910): bee580d4 40dc5b88 /system/lib/libdvm.so
I/DEBUG ( 910): #01 bee580d8 40e34aa8 /system/lib/libdvm.so
I/DEBUG ( 910): bee580dc 40db78c4 /system/lib/libdvm.so (dvmCollectGarbageInternal(GcSpec const*)+200)
I/DEBUG ( 910): #02 bee580e0 bee58124 [stack]
I/DEBUG ( 910): bee580e4 40df9095 /system/lib/libdvm.so
I/DEBUG ( 910): bee580e8 5855879e /data/dalvik-cache/system@framework@core.jar@classes.dex
I/DEBUG ( 910): bee580ec 40087010
I/DEBUG ( 910): bee580f0 5855879e /data/dalvik-cache/system@framework@core.jar@classes.dex
I/DEBUG ( 910): bee580f4 410be000 /dev/ashmem/dalvik-aux-structure (deleted)
I/DEBUG ( 910): bee580f8 00000000
I/DEBUG ( 910): bee580fc 00000000
I/DEBUG ( 910): bee58100 000006db
I/DEBUG ( 910): bee58104 410be000 /dev/ashmem/dalvik-aux-structure (deleted)
I/DEBUG ( 910): bee58108 00000000
I/DEBUG ( 910): bee5810c 410f55cc /dev/ashmem/dalvik-aux-structure (deleted)
I/DEBUG ( 910): bee58110 412569d8 /dev/ashmem/dalvik-heap (deleted)
I/DEBUG ( 910): bee58114 41248338 /dev/ashmem/dalvik-heap (deleted)
I/DEBUG ( 910): bee58118 41248338 /dev/ashmem/dalvik-heap (deleted)
I/DEBUG ( 910): bee5811c 40e3c1b8 /system/lib/libdvm.so
I/DEBUG ( 910): ........ ........
- Sie könnten versuchen, die Buchung in der Android-Plattform-Gruppe (groups.google.com/forum/?fromgroups=#!forum/android-Plattform) . Auch, stuerzt es ab in anderen Prozessen als der zygote und sieht Ihr Programm über systemeigene Komponenten? Wenn dem so ist, haben Sie möglicherweise einen Fehler verursacht heap-Beschädigung - siehe die Diskussion in der crash-Bericht für einige Ideen: code.google.com/p/android/issues/....
- FWIW, dass stack-trace zeigt im Allgemeinen an, dass der verwaltete heap (d.h. die "Dalvik-heap", dass die GC schafft es, im Gegensatz zu den
malloc
heap) beschädigt wurde.scanObject
passiert, werden die erste Sache, die versucht zu jagen, die Klasse eines Objekts Zeiger während der GC. Am häufigsten liegt die Ursache in bit-native-code, die kritzeleien am Speicher sollte es nicht. - Ich habe auch das gleiche Problem. Hast du eine Lösung gefunden werden?
Du musst angemeldet sein, um einen Kommentar abzugeben.
Ah, es hat mich ziemlich lange Zeit, die situation zu analysieren, die für mich mit einem ähnlichen Problem. Hoffe, dass meine Analyse hilft Ihnen .
Mit meinem problem , das problem ist, weil der Speicher Neuordnung durch den compiler . In dalvik mehrere threads teilen sich gemeinsamen Speicher ASHMEM . Diese ASHMEM möglicherweise beschädigt wurde, weil der Speicher re-Bestellung durch compiler-Optimierung .
Um zu vermeiden, memory-Neuordnung bei bestimmten Punkt execute memory-Barriere (AKA membar) .Überprüfen Sie diesen link für die Ausführung membar
Einfach eine memory barrier
ANDROID_MEMBAR_BARRIER()
vor-Objekt-Zuordnung und-Objekt zu befreien, in Müll-Sammel-Speicher Zuweisung(wie dalvik/vm/alloc/alloc.cpp) und in class.cpp , array.cpp und proxy.cpp in dalvik-Verzeichnis des android-source-code . Dies sollte das Problem beheben.Weitere Informationen zu Memory-Barriere pls check folgende links
memory-Barriere
Beispiel
white paper auf Hardware-Ansicht von Memory-Barrieren
Meinst du setzen ANDROID_MEMBAR_FULL() hinter allen dvmMalloc wie code in das folgende?
Und Wo ist der Speicher free-Funktion in die garbage collection-Thread? danke
dvmMalloc
tut, ist die Sperre auf dem heap und Mutexe gehören die memory-Barrieren per definition.