Сборка мусора Android dalvik может дать сбой?

Мы работаем над проектом для Android jelly bean. Наша платформа основана на ARM, а версия ядра 3.1.10. В процессе разработки мы обнаружили, что вероятность сбоя приложения в dalvik очень мала. Судя по следующему журналу обратной трассировки, сбой произошел во время работы функции сборки мусора. После использования addr2line для анализа адреса компьютера мы обнаружили, что obj->clazz стал адресом нарушения, когда возникла проблема.

Поток кода: (dvmHeapScanMarkedObjects -> processMarkStack-> scanObject-> (IS_CLASS_FLAG_SET(obj->clazz,CLASS_ISARRAY)))

Теперь мы застряли здесь и не можем найти способ решить эту проблему. Поэтому нам нужно больше предложений и помощи.

Кто-нибудь знает эту проблему или как продолжать проверять ее?

Журнал обратной трассировки, как показано ниже:

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

android dalvik
person 建翰 陳    schedule 25.02.2013    source источник
comment
Вы можете попробовать опубликовать сообщение в группе платформы Android (groups.google.com/ форум/?fromgroups=#!forum/android-platform). Кроме того, происходит ли сбой в процессах, отличных от zygote, и есть ли в вашей программе собственные части? Если это так, у вас может быть ошибка, вызывающая повреждение кучи. Некоторые идеи см. в обсуждении в отчете о сбое: code.google.com/p/android/issues/.   -  person David J. Liszewski    schedule 25.02.2013
comment
FWIW, эта трассировка стека обычно указывает на то, что управляемая куча (т. е. куча Dalvik, которой управляет GC, в отличие от кучи malloc) была повреждена. scanObject оказывается первым, что пытается преследовать указатель класса объекта во время GC. Чаще всего причиной является какой-то фрагмент нативного кода, который пишет в памяти, чего не должен.   -  person fadden    schedule 12.03.2013
comment
Я также столкнулся с той же проблемой. Вы нашли решение этой проблемы?   -  person Aniket Awati    schedule 04.12.2013

Ответы (2)


arrow_upward
3
arrow_downward

Ах, мне потребовалось довольно много времени, чтобы проанализировать ситуацию для меня с аналогичной проблемой. Надеюсь, мой анализ вам поможет.

С моей проблемой проблема связана с переупорядочением памяти компилятором. В dalvik несколько потоков совместно используют общую память ASHMEM. Этот ASHMEM мог быть поврежден из-за переупорядочения памяти компилятором для оптимизации. Чтобы избежать переупорядочения памяти в определенной точке, выполните барьер памяти (мембар AKA). variable">Проверьте эту ссылку для выполнения membar

Просто установите барьер памяти ANDROID_MEMBAR_BARRIER() перед выделением объектов и освобождением объектов в распределителе памяти для сбора мусора (например, dalvik/vm/alloc/alloc.cpp) и в class.cpp , array.cpp и proxy.cpp в каталоге dalvik исходного кода Android. . Это должно решить проблему.

Для получения дополнительной информации о барьере памяти, пожалуйста, проверьте следующие ссылки

барьер памяти

пример

технический документ по аппаратному представлению барьеров памяти

person Imposter    schedule 26.02.2013
comment
Если вы изменяете кучу, вам нужно удерживать блокировку кучи, и в этом случае вам предоставляются барьеры памяти. Если вы не держите блокировку кучи, все барьеры в мире не спасут вас от проблем с одновременным доступом. Дополнительные сведения о барьерах памяти и общих проблемах SMP на Android см. на странице developer.android.com/ обучение/статьи/smp.html . - person fadden; 12.03.2013

arrow_upward
0
arrow_downward

Вы имеете в виду поставить ANDROID_MEMBAR_FULL() позади всех dvmMalloc, как код в следующем? И где функция освобождения памяти в потоке сборки мусора? Спасибо

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();
person 建翰 陳    schedule 26.02.2013
comment
Введение дополнительных барьеров памяти не требуется. Первое, что делает dvmMalloc, — это блокирует кучу, а мьютексы по определению включают в себя барьеры памяти. - person fadden; 12.03.2013