Làm thế nào tôi có thể sử dụng đầu ra trong logcat sau khi một tín hiệu Fatal 11 để tìm ra nơi tôi nhận được lỗi từ trong mã nguồn gốc android?

Tôi có một lỗi để sửa lỗi bật lên rất nhiều. Đó là một tín hiệu gây tử vong 11. Vấn đề là chương trình không sụp đổ trong bất kỳ mã nguồn gốc của tôi, nhưng cái gì khác đang gây ra nó. Tôi đã sau đây từ logcat, tôi không biết thuật ngữ thích hợp cho việc này:Làm thế nào tôi có thể sử dụng đầu ra trong logcat sau khi một tín hiệu Fatal 11 để tìm ra nơi tôi nhận được lỗi từ trong mã nguồn gốc android?

03-10 12:50:14.419 F/libc (3429): Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1) 
03-10 12:50:14.819 I/DEBUG (11778): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 
03-10 12:50:14.819 I/DEBUG (11778): Build fingerprint: 'hp/hp_tenderloin/tenderloin:4.0.4/IMM76I/330937:user/release-keys' 
03-10 12:50:14.819 I/DEBUG (11778): pid: 3429, tid: 3702 >>> com.RefinedCode.handocr <<< 
03-10 12:50:14.819 I/DEBUG (11778): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000000 
03-10 12:50:14.819 I/DEBUG (11778): r0 004a1e30 r1 33400001 r2 004a1e30 r3 00000000 
03-10 12:50:14.819 I/DEBUG (11778): r4 414b3da8 r5 004b6cb8 r6 00000007 r7 4e348f80 
03-10 12:50:14.819 I/DEBUG (11778): r8 4e766c10 r9 4e348f78 10 00000008 fp 4e766c24 
03-10 12:50:14.819 I/DEBUG (11778): ip 2ac56f9c sp 4e766c08 lr 2ac254dd pc 2b10ba64 cpsr 60010010 
03-10 12:50:14.819 I/DEBUG (11778): d0 0000000000000000 d1 0000000000000000 
03-10 12:50:14.819 I/DEBUG (11778): d2 0000000000000000 d3 0000000000000000 
03-10 12:50:14.819 I/DEBUG (11778): d4 4379000044310000 d5 437a0000442d8000 
03-10 12:50:14.819 I/DEBUG (11778): d6 bff921fb54400000 d7 442a556b00000000 
03-10 12:50:14.819 I/DEBUG (11778): d8 4392103d3089705f d9 45a820003c711706 
03-10 12:50:14.829 I/DEBUG (11778): d10 3f80000000000000 d11 3f800000000000ff 
03-10 12:50:14.829 I/DEBUG (11778): d12 4017ef9a000000ff d13 000000003f800000 
03-10 12:50:14.829 I/DEBUG (11778): d14 3fee940d6bb98cc4 d15 3ff0000000000000 
03-10 12:50:14.829 I/DEBUG (11778): d16 0000000000000000 d17 0000000042ff0000 
03-10 12:50:14.829 I/DEBUG (11778): d18 3fc5555555555549 d19 bf9b6d5dd2eaade7 
03-10 12:50:14.829 I/DEBUG (11778): d20 3ef4e83ec07d9f84 d21 be5ae1fd202f348f 
03-10 12:50:14.829 I/DEBUG (11778): d22 bc7a626331000000 d23 3de5d93a5acfd57c 
03-10 12:50:14.829 I/DEBUG (11778): d24 ff00000000000000 d25 0000d8050000a9d8 
03-10 12:50:14.829 I/DEBUG (11778): d26 0003e14a0018a8a0 d27 0002d8070002a9da 
03-10 12:50:14.829 I/DEBUG (11778): d28 0000000000ff0000 d29 090a0b0c0d0e0f10 
03-10 12:50:14.829 I/DEBUG (11778): d30 0000000100000001 d31 0000000100000001 
03-10 12:50:14.829 I/DEBUG (11778): scr 60000010 
03-10 12:50:14.829 I/DEBUG (11778): 
03-10 12:50:14.999 I/DEBUG (11778):   #00 pc 00088a64 /system/lib/libskia.so (_ZNK6SkPath7isEmptyEv) 
03-10 12:50:14.999 I/DEBUG (11778):   #01 pc 0006e4da /system/lib/libandroid_runtime.so 
03-10 12:50:15.009 I/DEBUG (11778):   #02 pc 0001edb0 /system/lib/libdvm.so (dvmPlatformInvoke) 
03-10 12:50:15.009 I/DEBUG (11778):   #03 pc 00059050 /system/lib/libdvm.so (_Z16dvmCallJNIMethodPKjP6JValuePK6MethodP6Thread) 
03-10 12:50:15.009 I/DEBUG (11778): 
03-10 12:50:15.009 I/DEBUG (11778): code around pc: 
03-10 12:50:15.009 I/DEBUG (11778): 2b10ba44 e5903014 e3530000 03a00001 012fff1e .0....S......./. 
03-10 12:50:15.009 I/DEBUG (11778): 2b10ba54 e3530001 13a00000 112fff1e e590300c ..S......./..0.. 
03-10 12:50:15.009 I/DEBUG (11778): 2b10ba64 e5d30000 e2700001 33a00000 e12fff1e ......p....3../. 
03-10 12:50:15.009 I/DEBUG (11778): 2b10ba74 e1a03002 e5912008 e92d4010 e1530002 .0... [email protected] 
03-10 12:50:15.009 I/DEBUG (11778): 2b10ba84 e1a04000 3a000004 eddf7a09 edc07a01 [email protected]:.z...z.. 
03-10 12:50:15.009 I/DEBUG (11778): 
03-10 12:50:15.009 I/DEBUG (11778): code around lr: 
03-10 12:50:15.009 I/DEBUG (11778): 2ac254bc ed78f7ca 463a4621 4605466e f7fc4668 ..x.!F:FnF.FhF.. 
03-10 12:50:15.009 I/DEBUG (11778): 2ac254cc 4628faa3 bdf0b005 4610b510 ed70f7ca ..(F.......F..p. 
03-10 12:50:15.009 I/DEBUG (11778): 2ac254dc bf00bd10 4610b510 f7ca4619 bd10ed70 .......F.F..p... 
03-10 12:50:15.009 I/DEBUG (11778): 2ac254ec 4610b510 ed70f7ca bf00bd10 4610b510 ...F..p........F 
03-10 12:50:15.009 I/DEBUG (11778): 2ac254fc ed70f7ca bf00bd10 2030b570 f7c74615 ..p.....p.0 .F.. 
03-10 12:50:15.009 I/DEBUG (11778): 
03-10 12:50:15.009 I/DEBUG (11778): stack: 
03-10 12:50:15.009 I/DEBUG (11778):  4e766bc8 004b5270 [heap] 
03-10 12:50:15.009 I/DEBUG (11778):  4e766bcc 004a1ac0 [heap] 
03-10 12:50:15.009 I/DEBUG (11778):  4e766bd0 1d600005 
03-10 12:50:15.009 I/DEBUG (11778):  4e766bd4 2b2e62e3 /system/lib/libdvm.so 
03-10 12:50:15.009 I/DEBUG (11778):  4e766bd8 004b2de0 [heap] 
03-10 12:50:15.009 I/DEBUG (11778):  4e766bdc 004b6cb8 [heap] 
03-10 12:50:15.009 I/DEBUG (11778):  4e766be0 004b2de0 [heap] 
03-10 12:50:15.009 I/DEBUG (11778):  4e766be4 2ac1c5c1 /system/lib/libandroid_runtime.so 
03-10 12:50:15.009 I/DEBUG (11778):  4e766be8 41477d58 /dev/ashmem/dalvik-LinearAlloc (deleted) 
03-10 12:50:15.009 I/DEBUG (11778):  4e766bec 004b6cb8 [heap] 
03-10 12:50:15.009 I/DEBUG (11778):  4e766bf0 00000004 
03-10 12:50:15.009 I/DEBUG (11778):  4e766bf4 4e348ee8 
03-10 12:50:15.019 I/DEBUG (11778):  4e766bf8 2b524910 /dev/ashmem/dalvik-heap (deleted) 
03-10 12:50:15.019 I/DEBUG (11778):  4e766bfc 2b524910 /dev/ashmem/dalvik-heap (deleted) 
03-10 12:50:15.019 I/DEBUG (11778):  4e766c00 df0027ad 
03-10 12:50:15.019 I/DEBUG (11778):  4e766c04 00000000 
03-10 12:50:15.019 I/DEBUG (11778): #01 4e766c08 414b3da8 /dev/ashmem/dalvik-LinearAlloc (deleted) 
03-10 12:50:15.019 I/DEBUG (11778):  4e766c0c 2b2b0db4 /system/lib/libdvm.so

Thông thường khi tôi nhận được loại hình báo lỗi, đó là vì một số các mã gốc Tôi wrote rối tung lên, như truy cập vào một yếu tố không hợp lệ của véc tơ hoặc thứ gì đó.

Sự cố thường xảy ra đôi khi sau khi một trong các hàm gốc của tôi chạy (nhưng không phải trong đó), do đó, thật khó để tôi tìm ra cách khắc phục khi tôi không nhận được số dòng nơi sự cố xảy ra . Có cách nào tôi có thể sử dụng đầu ra này để có thêm thông tin về vấn đề này không? Tôi không biết thuật ngữ thích hợp cho đầu ra này là gì vì vậy tôi đang gặp khó khăn khi tìm kiếm câu trả lời. Nếu bất cứ ai ở đây có kinh nghiệm với điều này tôi thực sự muốn có thể sử dụng điều này!

Cảm ơn, Zach

Nguồn

2013-03-10 Zach

để bắt đầu, bạn có thể thêm nhật ký trong mã gốc để xác định lỗi –

Đó là những gì tôi đã làm, lỗi không xảy ra trong mã gốc của tôi. – Zach

u có thể dán nhật ký của phần trên điểm bạn nhận được lỗi này, cũng kiểm tra bài đăng này http://stackoverflow.com/questions/10423128/android-fatal-signal-11 –

Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1) là null pointer dereferencing. Như bạn có thể thấy địa chỉ là 0x00000000, do đó hệ thống đang cố gắng đọc từ địa chỉ 0.

03-10 12:50:14.999 I/DEBUG (11778):   #00 pc 00088a64 /system/lib/libskia.so (_ZNK6SkPath7isEmptyEv) 
03-10 12:50:14.999 I/DEBUG (11778):   #01 pc 0006e4da /system/lib/libandroid_runtime.so 
03-10 12:50:15.009 I/DEBUG (11778):   #02 pc 0001edb0 /system/lib/libdvm.so (dvmPlatformInvoke) 
03-10 12:50:15.009 I/DEBUG (11778):   #03 pc 00059050 /system/lib/libdvm.so (_Z16dvmCallJNIMethodPKjP6JValuePK6MethodP6Thread)

Tai nạn của bạn là SkPath7isEmptyEv ->SkPath.isEmpty(). (Điều này được gọi là name mangling)

Vì vậy, đây rõ ràng là sự cố hệ thống/khung. Tôi sẽ cố gắng tạo một mã số tối thiểu để tái tạo vấn đề để hiểu bản chất của nó và cũng tìm kiếm các báo cáo lỗi đã biết. Tốt nhất là tìm một cách giải quyết khác không nhấn đường dẫn mã này.

Nguồn

2013-03-11 10:38:30 auselen

Có thể vấn đề là với cách lớp học đang được sử dụng và sự cố có thể được khắc phục trong các nguồn ứng dụng. 'isEmpty()' không phải là một phương thức ảo, vì vậy có thể con trỏ 'this' này là null. (Phương pháp đó thực sự không làm được gì nhiều, vì vậy tập hợp những thứ có thể bị sai sẽ bị giới hạn.) Nếu bạn muốn khẳng định rằng nó vẫn là lỗi cho thư viện để phân biệt lỗi trong tình huống này, tôi sẽ không tranh cãi. :-) – fadden

@fadden Tôi không biết mức độ sâu trong chức năng là PC nhưng "r0 004a1e30 r1 33400001 r2 004a1e30 r3 00000000" là r3 không có giá trị. 'this' nên có trên' r0' afaik tuy nhiên kỹ năng gỡ lỗi C++ của tôi không có ở đâu gần một chuyên gia. – auselen

Hmm. Nhìn vào disassembly, tôi đoán 'this' là hợp lệ nhưng' fPathRef' là 'NULL'. (Các lệnh tải đầu tiên * (R0 + 0) vào R3, tải lệnh thứ hai * (R3 + 16) vào R0, tiếp theo hai so sánh R0 bằng 0 và lưu nó như là một bool trong R0. Nó đang rơi vào lệnh thứ hai.) hoàn cảnh nào dẫn đến tình trạng này. – fadden

Làm thế nào tôi có thể sử dụng đầu ra trong logcat sau khi một tín hiệu Fatal 11 để tìm ra nơi tôi nhận được lỗi từ trong mã nguồn gốc android?

Trả lời

Các vấn đề liên quan