2013-02-25 27 views
6

Chúng tôi đang làm việc trên một dự án cho đậu thạch Android. Nền tảng của chúng tôi là dựa trên cánh tay và phiên bản hạt nhân là 3.1.10. Trong quá trình phát triển của chúng tôi, chúng tôi nhận thấy rằng có rất ít khả năng xảy ra sự cố ứng dụng trong dalvik. Dựa trên nhật ký backtrace sau, sự cố xuất hiện trong chức năng thu gom rác thải. Sau khi sử dụng addr2line để phân tích địa chỉ máy tính, chúng tôi thấy obj-> clazz trở thành địa chỉ vi phạm khi vấn đề đã xảy ra.Bộ sưu tập rác dalvik Android có thể bị lỗi?

Dòng mã này là: (dvmHeapScanMarkedObjects -> processMarkStack-> scanObject -> (IS_CLASS_FLAG_SET (obj-> clazz, CLASS_ISARRAY)))

Bây giờ chúng ta đang bị mắc kẹt ở đây và không thể tìm thấy một cách để giải quyết nó. Vì vậy, chúng tôi cần thêm gợi ý và trợ giúp.

Có ai biết vấn đề này hoặc cách tiếp tục kiểm tra không?

Nhật ký backtrace như sau:

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):   ........ ........ 
+2

Bạn có thể thử đăng trong nhóm Nền tảng Android (https://groups.google.com/forum/?fromgroups=#!forum/android-platform). Ngoài ra, nó sụp đổ trong các quá trình khác với zygote và chương trình của bạn có phần gốc không? Nếu có, bạn có thể gặp lỗi gây ra lỗi tham nhũng - hãy xem cuộc thảo luận trong báo cáo sự cố cho một số ý tưởng: https://code.google.com/p/android/issues/detail?id=10574&can=1&q=scanObject&colspec=ID % 20Type% 20Status% 20Owner% 20Summary% 20Stars. –

+1

FWIW, rằng theo dõi ngăn xếp thường chỉ ra rằng heap được quản lý (tức là "đống Dalvik" mà GC quản lý, trái ngược với đống 'malloc') đã bị hỏng. 'scanObject' xảy ra là điều đầu tiên cố gắng đuổi theo một con trỏ lớp của đối tượng trong GC. Thông thường, nguyên nhân là một số mã nguồn gốc viết nguệch ngoạc trên bộ nhớ nó không nên. – fadden

+0

Tôi cũng đã gặp phải vấn đề tương tự. Bạn đã tìm thấy một giải pháp cho điều này? –

Trả lời

3

Ah nó đã cho tôi một thời gian khá dài để phân tích tình hình cho tôi với một vấn đề tương tự. Hy vọng phân tích của tôi sẽ giúp bạn.

Với sự cố của tôi, sự cố là do Bộ nhớ sắp xếp lại trình biên dịch. Trong dalvik một số chủ đề chia sẻ bộ nhớ chung ASHMEM. ASHMEM này có thể đã bị hỏng do bộ nhớ sắp xếp lại bởi trình biên dịch để tối ưu hóa. Để tránh bộ nhớ sắp xếp lại tại điểm cụ thể thực hiện rào cản bộ nhớ (thanh ghi AKA). Check this link for executing membar

Chỉ cần đặt hàng rào bộ nhớ ANDROID_MEMBAR_BARRIER() trước khi phân bổ đối tượng và giải phóng đối tượng trong bộ phân bổ bộ nhớ thu gom rác (như dalvik/vm/alloc/alloc.cpp) và trong class.cpp, array.cpp và proxy.cpp trong dalvik thư mục mã nguồn Android. Điều này sẽ giải quyết vấn đề.

Đối biết thêm thông tin về kiểm tra pls Memory rào cản liên kết sau

memory barrier

example

giấy trắng trên Hardware View of Memory Barriers

+2

Nếu bạn đang sửa đổi heap, bạn cần phải giữ khóa heap, trong đó các rào cản bộ nhớ trường hợp được cung cấp cho bạn.Nếu bạn không giữ khóa heap, tất cả các rào cản trên thế giới sẽ không giúp bạn tiết kiệm từ các vấn đề truy cập đồng thời. Để biết thêm thông tin về các rào cản bộ nhớ và các vấn đề SMP chung trên Android, hãy xem http://developer.android.com/training/articles/smp.html. – fadden

0

Bạn có nghĩa là đặt ANDROID_MEMBAR_FULL() đằng sau tất cả dvmMalloc giống như mã trong sau đây? Và chức năng bộ nhớ miễn phí ở đâu trong luồng thu gom rác? cảm ơn bạn

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(); 
+0

Giới thiệu các rào cản bộ nhớ bổ sung là không cần thiết. Điều đầu tiên 'dvmMalloc' làm là khóa heap, và mutexes bao gồm các rào cản bộ nhớ theo định nghĩa. – fadden