La garbage collection dalvik di Android potrebbe bloccarsi?

Stiamo lavorando a un progetto per Android jelly bean. La nostra piattaforma è basata su arm e la versione del kernel è 3.1.10. Nel nostro processo di sviluppo, abbiamo scoperto che esiste una probabilità molto bassa che il crash dell'applicazione si sia verificato in dalvik. In base al seguente registro di backtrace, l'arresto anomalo si è verificato durante la funzione di garbage collection. Dopo aver usato addr2line per analizzare l'indirizzo del pc, abbiamo scoperto che obj-> clazz è diventato un indirizzo violato quando il problema si è verificato.La garbage collection dalvik di Android potrebbe bloccarsi?

Il flusso di codice è: (dvmHeapScanMarkedObjects -> processMarkStack-> scanObject -> (IS_CLASS_FLAG_SET (obj-> Clazz, CLASS_ISARRAY)))

Ora siamo bloccati qui e non riesce a trovare un modo per risolverlo Quindi abbiamo bisogno di più suggerimenti e aiuto.

Qualcuno conosce questo problema o come continuare a controllarlo?

Il registro backtrace come di seguito:

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/[email protected]@[email protected] 
I/DEBUG ( 910):   bee580ec 40087010 
I/DEBUG ( 910):   bee580f0 5855879e /data/dalvik-cache/[email protected]@[email protected] 
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):   ........ ........

fonte

2013-02-25 建翰陳

Si potrebbe provare distacco in gruppo piattaforma Android (https://groups.google.com/forum/?fromgroups=#!forum/android-platform). Inoltre, si blocca in processi diversi da zigote e il tuo programma ha parti native? In tal caso, potresti avere un bug che causa il danneggiamento dell'heap - consulta la discussione nel rapporto sugli arresti anomali per alcune idee: https://code.google.com/p/android/issues/detail?id=10574&can=1&q=scanObject&colspec=ID % 20Type% 20Status% 20Owner% 20Summary% 20Stars. –

FWIW, quella traccia dello stack indica generalmente che l'heap gestito (ad esempio "l'heap Dalvik" gestito dal GC, in contrasto con l'heap 'malloc') è stato danneggiato. 'scanObject' sembra essere la prima cosa che cerca di inseguire il puntatore di classe di un oggetto durante il GC. Molto spesso la causa è un po 'di codice nativo che scarabocchia sulla memoria che non dovrebbe. – fadden

Ho anche incontrato lo stesso problema. Hai trovato una soluzione a questo? –

Ah mi c'è voluto molto tempo per analizzare la situazione per me con un problema simile. Spero che la mia analisi ti aiuti.

Con il mio problema, il problema è dovuto al riordino della memoria da parte del compilatore. In dalvik diversi thread condividono la memoria comune ASHMEM. Questo ASHMEM potrebbe essere stato danneggiato a causa del riordino della memoria da parte del compilatore per l'ottimizzazione. Per evitare il riordino della memoria in un punto particolare, eseguire la barriera di memoria (AKA membar). Check this link for executing membar

Basta mettere una barriera memoria ANDROID_MEMBAR_BARRIER() prima assegnazione oggetto e oggetto liberando in allocatore di memoria immondizia di raccolta (come dalvik/vm/alloc/alloc.cpp) e in class.cpp, array.cpp e proxy.cpp in dalvik directory del codice sorgente di Android. Questo dovrebbe risolvere il problema.

Per informazioni circa assegno pls barriera di memoria seguenti collegamenti

memory barrier

example

carta bianca su Hardware View of Memory Barriers

fonte

2013-02-26 10:57:33 Imposter

Se si sta modificando l'heap, è necessario mantenere il blocco dell'heap, nel qual caso vengono fornite le barriere della memoria.Se non si tiene il blocco dell'heap, tutte le barriere nel mondo non ti salveranno da problemi di accesso simultanei. Per ulteriori informazioni sulle barriere della memoria e problemi SMP generali su Android, vedere http://developer.android.com/training/articles/smp.html. – fadden

Vuoi dire mettere ANDROID_MEMBAR_FULL() dietro tutto dvmMalloc proprio come codice il seguente? E dov'è la funzione di memoria libera nel flusso della raccolta dati obsoleti? grazie

static bool createInitialClasses() { 
    /* 
    * Initialize the class Class. This has to be done specially, particularly 
    * because it is an instance of itself. 
    */ 
    ClassObject* clazz = (ClassObject*) 
     dvmMalloc(classObjectSize(CLASS_SFIELD_SLOTS), ALLOC_NON_MOVING); 
    ANDROID_MEMBAR_FULL();

fonte

2013-02-26 13:38:25

L'introduzione di barriere di memoria aggiuntive non è necessaria. La prima cosa che 'dvmMalloc' fa è bloccare l'heap e i mutex includono le barriere della memoria per definizione. – fadden

La garbage collection dalvik di Android potrebbe bloccarsi?

risposta

Problemi correlati