我们正在开发一个针对Android jelly bean的项目.我们的平台是基于arm的,内核版本是3.1.10.在我们的开发过程中,我们发现dalvik中发生应用程序崩溃的可能性很小.基于以下回溯日志,垃圾收集功能期间出现崩溃.在使用addr2line分析pc地址后,我们发现当问题发生时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@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): ........ ........
啊，我花了很长时间才为我分析类似问题的情况。希望我的分析对你有帮助。
对于我的问题，问题是由于编译器对内存进行了重新排序。在 dalvik 中，多个线程共享公共内存 ASHMEM 。由于编译器为了优化而对内存进行了重新排序，因此该 ASHMEM 可能已被损坏。为了避免在特定点执行内存重新排序，请执行内存屏障（AKA membar）。检查此链接以执行 membar
ANDROID_MEMBAR_BARRIER()只需在垃圾收集内存分配器（如dalvik/vm/alloc/alloc.cpp）和android源代码dalvik目录中的class.cpp，array.cpp和proxy.cpp中的对象分配和对象释放之前放置一个内存屏障即可。这应该可以解决问题。
有关内存屏障的更多信息，请检查以下链接
内存屏障硬件视图白皮书
| 归档时间： |
|
| 查看次数： |
5873 次 |
| 最近记录： |