Tín hiệu gây tử vong của Android 11 (SIGSEGV) ở 0x636f7d89 (code = 1). Làm thế nào nó có thể được theo dõi xuống?

Tôi đã đọc các bài đăng khác về việc theo dõi các lý do để có được một SIGSEGVứng dụng Android. Tôi dự định truy quét ứng dụng của mình để tìm NullPointers có thể liên quan đến việc sử dụng Canvas, nhưng mỗi lần tôi SIGSEGVlại mở một địa chỉ bộ nhớ khác. Thêm vào đó tôi đã thấy code=1và code=2. Nếu địa chỉ bộ nhớ là 0x00000000, tôi sẽ có một đầu mối, đó là NullPulum.

Cái cuối cùng tôi nhận được là code=2:

A/libc(4969): Fatal signal 11 (SIGSEGV) at 0x42a637d9 (code=2)

Bất kỳ đề xuất về cách theo dõi này xuống?

Tôi có một nghi ngờ, nhưng tôi chưa thích thử nghiệm nó. Ứng dụng của tôi sử dụng API OSMDroid để ánh xạ ngoại tuyến. Lớp OverlayItem đại diện cho các điểm đánh dấu / nút trên bản đồ. Tôi có một Dịch vụ thu thập dữ liệu qua mạng để điền vào OverlayItem sau đó được hiển thị trên bản đồ. Trong nỗ lực đơn giản hóa thiết kế của mình, tôi đã mở rộng OverlayItem thành lớp NodeOverlayItem của riêng tôi, bao gồm một số thuộc tính bổ sung tôi sử dụng trong Hoạt động giao diện người dùng và trong Dịch vụ. Điều này đã cho tôi một điểm thông tin Mục duy nhất cho Giao diện người dùng và Dịch vụ. Tôi đã sử dụng Ý định để phát đến Hoạt động để làm mới bản đồ UI khi có gì đó thay đổi. Hoạt động liên kết với Dịch vụ và có một phương thức Dịch vụ để lấy danh sách của NodeOverlayItem. Tôi nghĩ rằng đó có thể là việc sử dụng OverlayItem API của OSMDroid, và Dịch vụ của tôi cập nhật thông tin nút cùng một lúc. (một vấn đề tương tranh)

Khi tôi viết điều này, tôi nghĩ đó thực sự là vấn đề. Đau đầu không phải là tách Node và OverlayItem khỏi NodeOverlayItem, đó là Hoạt động sẽ cần một số dữ liệu từ Nút, mà Dịch vụ giữ. Ngoài ra, khi Hoạt động được tạo (onResume, v.v ...), các đối tượng OverlayItem sẽ cần được tạo lại từ dữ liệu Nút mà Dịch vụ đang duy trì trong khi Hoạt động vắng mặt. ví dụ: Bạn khởi động ứng dụng, Dịch vụ thu thập dữ liệu, Giao diện người dùng hiển thị, bạn đi đến Trang chủ, sau đó quay lại ứng dụng, Hoạt động sẽ cần phải kéo và tạo lại OverlayItem từ dữ liệu nút Dịch vụ mới nhất.

Tôi biết đây không phải là một câu hỏi hay hoặc rõ ràng. Nó giống như tất cả các câu hỏi SO của tôi là thích hợp hoặc tối nghĩa. Nếu bất cứ ai có một gợi ý về cách giải thích những SIGSEGVlỗi đó, nó sẽ được đánh giá rất cao!

CẬP NHẬT Đây là sự cố mới nhất được ghi lại trong một phiên gỡ lỗi. Tôi có 3 trong số các thiết bị này đang được sử dụng để thử nghiệm và chúng không bị hỏng một cách đáng tin cậy khi tôi đang phát triển và thử nghiệm. Tôi đã thêm một chút chỉ để ghi nhật ký GC có thể được lưu ý. Bạn có thể thấy vấn đề có lẽ không liên quan đến cạn kiệt bộ nhớ.

03-03 02:02:38.328: I/CommService(7477): Received packet from: 192.168.1.102
03-03 02:02:38.328: I/CommService(7477): Already processed this packet. It's a re-broadcast from another node, or from myself. It's not a repeat broadcast though.
03-03 02:02:38.406: D/CommService(7477): Checking OLSRd info...
03-03 02:02:38.460: D/CommService(7477): Monitoring nodes...
03-03 02:02:38.515: D/dalvikvm(7477): GC_CONCURRENT freed 2050K, 16% free 17151K/20359K, paused 3ms+6ms
03-03 02:02:38.515: I/CommService(7477): Received packet from: 192.168.1.102
03-03 02:02:38.515: D/CommService(7477): Forwarding packet (4f68802cf10684a83ac4936ebb3c934d) along to other nodes.
03-03 02:02:38.609: I/CommService(7477): Received packet from: 192.168.1.100
03-03 02:02:38.609: D/CommService(7477): Forwarding packet (e4bc81e91ec92d06f83e03068f52ab4) along to other nodes.
03-03 02:02:38.609: D/CommService(7477): Already processed this packet: 4204a5b27745ffe5e4f8458e227044bf
03-03 02:02:38.609: A/libc(7477): Fatal signal 11 (SIGSEGV) at 0x68f52abc (code=1)
03-03 02:02:38.914: I/DEBUG(4008): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
03-03 02:02:38.914: I/DEBUG(4008): Build fingerprint: 'Lenovo/IdeaTab_A1107/A1107:4.0.4/MR1/eng.user.20120719.150703:user/release-keys'
03-03 02:02:38.914: I/DEBUG(4008): pid: 7477, tid: 7712  >>> com.test.testm <<<
03-03 02:02:38.914: I/DEBUG(4008): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 68f52abc
03-03 02:02:38.914: I/DEBUG(4008):  r0 68f52ab4  r1 412ef268  r2 4d9c3bf4  r3 412ef268
03-03 02:02:38.914: I/DEBUG(4008):  r4 001ad8f8  r5 4d9c3bf4  r6 412ef268  r7 4c479df8
03-03 02:02:38.914: I/DEBUG(4008):  r8 4d9c3c0c  r9 4c479dec  10 46cf260a  fp 4d9c3c24
03-03 02:02:38.914: I/DEBUG(4008):  ip 40262a04  sp 4d9c3bc8  lr 402d01dd  pc 402d0182  cpsr 00000030
03-03 02:02:38.914: I/DEBUG(4008):  d0  00000001000c0102  d1  3a22364574614c7d
03-03 02:02:38.914: I/DEBUG(4008):  d2  403fc0000000007d  d3  363737343433350a
03-03 02:02:38.914: I/DEBUG(4008):  d4  49544341223a2273  d5  6f6567222c224556
03-03 02:02:38.914: I/DEBUG(4008):  d6  3a223645676e6f4c  d7  000000013835372d
03-03 02:02:38.914: I/DEBUG(4008):  d8  0000000000000000  d9  4040000000000000
03-03 02:02:38.914: I/DEBUG(4008):  d10 0000000000000000  d11 4040000000000000
03-03 02:02:38.914: I/DEBUG(4008):  d12 4040000000000000  d13 0000000000000021
03-03 02:02:38.914: I/DEBUG(4008):  d14 0000000000000000  d15 0000000000000000
03-03 02:02:38.914: I/DEBUG(4008):  d16 3fe62e42fefa39ef  d17 3ff0000000000000
03-03 02:02:38.914: I/DEBUG(4008):  d18 3fe62e42fee00000  d19 0000000000000000
03-03 02:02:38.914: I/DEBUG(4008):  d20 0000000000000000  d21 3ff0000000000000
03-03 02:02:38.914: I/DEBUG(4008):  d22 4028000000000000  d23 3ff0000000000000
03-03 02:02:38.914: I/DEBUG(4008):  d24 0000000000000000  d25 3ff0000000000000
03-03 02:02:38.914: I/DEBUG(4008):  d26 0000000000000000  d27 c028000000000000
03-03 02:02:38.914: I/DEBUG(4008):  d28 0000000000000000  d29 3ff0000000000000
03-03 02:02:38.914: I/DEBUG(4008):  d30 3ff0000000000000  d31 3fecccccb5c28f6e
03-03 02:02:38.914: I/DEBUG(4008):  scr 60000013
03-03 02:02:39.046: I/DEBUG(4008):          #00  pc 0006b182  /system/lib/libcrypto.so (EVP_DigestFinal_ex)
03-03 02:02:39.046: I/DEBUG(4008):          #01  pc 0006b1d8  /system/lib/libcrypto.so (EVP_DigestFinal)
03-03 02:02:39.054: I/DEBUG(4008):          #02  pc 0001f814  /system/lib/libnativehelper.so
03-03 02:02:39.054: I/DEBUG(4008):          #03  pc 0001ec30  /system/lib/libdvm.so (dvmPlatformInvoke)
03-03 02:02:39.054: I/DEBUG(4008):          #04  pc 00058c70  /system/lib/libdvm.so (_Z16dvmCallJNIMethodPKjP6JValuePK6MethodP6Thread)
03-03 02:02:39.054: I/DEBUG(4008): code around pc:
03-03 02:02:39.054: I/DEBUG(4008): 402d0160 0003151e 4604b570 f7ff460d 4620ff81  ....p..F.F.... F
03-03 02:02:39.054: I/DEBUG(4008): 402d0170 f7ff4629 bd70ff93 4604b570 460e6800  )F....p.p..F.h.F
03-03 02:02:39.054: I/DEBUG(4008): 402d0180 68834615 dd062b40 21fa4810 44784a10  .F.h@+...H.!.JxD
03-03 02:02:39.054: I/DEBUG(4008): 402d0190 f7c8447a 6821f80f 698a4620 47904631  zD....!h F.i1F.G
03-03 02:02:39.054: I/DEBUG(4008): 402d01a0 b1154606 68836820 6822602b b12b6a13  .F.. h.h+`"h.j+.
03-03 02:02:39.054: I/DEBUG(4008): code around lr:
03-03 02:02:39.054: I/DEBUG(4008): 402d01bc 68e06821 21006c4a ea0af7c4 bd704630  !h.hJl.!....0Fp.
03-03 02:02:39.054: I/DEBUG(4008): 402d01cc 00031492 000314b5 4604b570 ffcef7ff  ........p..F....
03-03 02:02:39.054: I/DEBUG(4008): 402d01dc 46204605 ff12f7ff bd704628 4604b573  .F F....(Fp.s..F
03-03 02:02:39.054: I/DEBUG(4008): 402d01ec 2102460d fb36f002 42ab6823 b123d020  .F.!..6.#h.B .#.
03-03 02:02:39.054: I/DEBUG(4008): 402d01fc b1136c5b f7c868e0 68a0fccf 05c26025  [l...h.....h%`..
03-03 02:02:39.054: I/DEBUG(4008): memory map around addr 68f52abc:
03-03 02:02:39.054: I/DEBUG(4008): 4d8c5000-4d9c4000 
03-03 02:02:39.054: I/DEBUG(4008): (no map for address)
03-03 02:02:39.054: I/DEBUG(4008): b0001000-b0009000 /system/bin/linker
03-03 02:02:39.054: I/DEBUG(4008): stack:
03-03 02:02:39.054: I/DEBUG(4008):     4d9c3b88  408d1f90  /system/lib/libdvm.so
03-03 02:02:39.054: I/DEBUG(4008):     4d9c3b8c  412ef258  /dev/ashmem/dalvik-heap (deleted)
03-03 02:02:39.054: I/DEBUG(4008):     4d9c3b90  00000001  
03-03 02:02:39.054: I/DEBUG(4008):     4d9c3b94  408d6c58  /system/lib/libdvm.so
03-03 02:02:39.054: I/DEBUG(4008):     4d9c3b98  408d6fa8  /system/lib/libdvm.so
03-03 02:02:39.054: I/DEBUG(4008):     4d9c3b9c  4c479dec  
03-03 02:02:39.054: I/DEBUG(4008):     4d9c3ba0  46cf260a  /system/framework/core.odex
03-03 02:02:39.054: I/DEBUG(4008):     4d9c3ba4  408735e7  /system/lib/libdvm.so
03-03 02:02:39.054: I/DEBUG(4008):     4d9c3ba8  412ef258  /dev/ashmem/dalvik-heap (deleted)
03-03 02:02:39.054: I/DEBUG(4008):     4d9c3bac  002bf070  [heap]
03-03 02:02:39.054: I/DEBUG(4008):     4d9c3bb0  412ef258  /dev/ashmem/dalvik-heap (deleted)
03-03 02:02:39.054: I/DEBUG(4008):     4d9c3bb4  00000000  
03-03 02:02:39.054: I/DEBUG(4008):     4d9c3bb8  412ef268  /dev/ashmem/dalvik-heap (deleted)
03-03 02:02:39.054: I/DEBUG(4008):     4d9c3bbc  00000000  
03-03 02:02:39.054: I/DEBUG(4008):     4d9c3bc0  df0027ad  
03-03 02:02:39.054: I/DEBUG(4008):     4d9c3bc4  00000000  
03-03 02:02:39.054: I/DEBUG(4008): #00 4d9c3bc8  001ad8f8  [heap]
03-03 02:02:39.054: I/DEBUG(4008):     4d9c3bcc  002ae0b8  [heap]
03-03 02:02:39.054: I/DEBUG(4008):     4d9c3bd0  00000004  
03-03 02:02:39.054: I/DEBUG(4008):     4d9c3bd4  402d01dd  /system/lib/libcrypto.so
03-03 02:02:39.054: I/DEBUG(4008): #01 4d9c3bd8  001ad8f8  [heap]
03-03 02:02:39.054: I/DEBUG(4008):     4d9c3bdc  002ae0b8  [heap]
03-03 02:02:39.054: I/DEBUG(4008):     4d9c3be0  00000004  
03-03 02:02:39.054: I/DEBUG(4008):     4d9c3be4  4024e817  /system/lib/libnativehelper.so
03-03 02:02:39.406: D/CommService(7477): Checking OLSRd info...
03-03 02:02:39.500: D/CommService(7477): Monitoring nodes...
03-03 02:02:39.500: D/dalvikvm(7477): GC_FOR_ALLOC freed 2073K, 16% free 17118K/20359K, paused 51ms
03-03 02:02:39.632: D/dalvikvm(7477): GC_CONCURRENT freed 1998K, 16% free 17162K/20359K, paused 2ms+4ms
03-03 02:02:40.406: D/CommService(7477): Checking OLSRd info...
03-03 02:02:40.445: D/CommService(7477): Monitoring nodes...
03-03 02:02:40.562: D/dalvikvm(7477): GC_CONCURRENT freed 2045K, 16% free 17158K/20359K, paused 3ms+4ms
03-03 02:02:41.406: D/CommService(7477): Checking OLSRd info...
03-03 02:02:41.445: D/CommService(7477): Monitoring nodes...
03-03 02:02:41.531: D/dalvikvm(7477): GC_CONCURRENT freed 2045K, 16% free 17154K/20359K, paused 3ms+12ms
03-03 02:02:42.406: D/CommService(7477): Checking OLSRd info...
03-03 02:02:42.445: D/CommService(7477): Monitoring nodes...
03-03 02:02:42.507: D/dalvikvm(7477): GC_CONCURRENT freed 2068K, 16% free 17128K/20359K, paused 3ms+4ms
03-03 02:02:42.679: D/dalvikvm(7477): GC_CONCURRENT freed 2006K, 16% free 17161K/20359K, paused 2ms+12ms
03-03 02:02:43.140: I/BootReceiver(1236): Copying /data/tombstones/tombstone_05 to DropBox (SYSTEM_TOMBSTONE)
03-03 02:02:43.210: D/dalvikvm(1236): GC_FOR_ALLOC freed 912K, 17% free 10207K/12295K, paused 62ms
03-03 02:02:43.265: D/dalvikvm(1236): GC_FOR_ALLOC freed 243K, 16% free 10374K/12295K, paused 49ms
03-03 02:02:43.265: I/dalvikvm-heap(1236): Grow heap (frag case) to 10.507MB for 196628-byte allocation

Đầu tiên, lấy dấu vết ngăn xếp bia mộ của bạn, nó sẽ được in mỗi khi ứng dụng của bạn gặp sự cố. Một cái gì đó như thế này:

*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'XXXXXXXXX'
pid: 1658, tid: 13086  >>> system_server <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 64696f7e
 r0 00000000  r1 00000001  r2 ad12d1e8  r3 7373654d
 r4 64696f72  r5 00000406  r6 00974130  r7 40d14008
 r8 4b857b88  r9 4685adb4  10 00974130  fp 4b857ed8
 ip 00000000  sp 4b857b50  lr afd11108  pc ad115ebc  cpsr 20000030
 d0  4040000040000000  d1  0000004200000003
 d2  4e72cd924285e370  d3  00e81fe04b1b64d8
 d4  3fbc71c7009b64d8  d5  3fe999999999999a
 d6  4010000000000000  d7  4000000000000000
 d8  4000000000000000  d9  0000000000000000
 d10 0000000000000000  d11 0000000000000000
 d12 0000000000000000  d13 0000000000000000
 d14 0000000000000000  d15 0000000000000000
 scr 80000012

         #00  pc 000108d8  /system/lib/libc.so
         #01  pc 0003724c  /system/lib/libxvi020.so
         #02  pc 0000ce02  /system/lib/libxvi020.so
         #03  pc 0000d672  /system/lib/libxvi020.so
         #04  pc 00010cce  /system/lib/libxvi020.so
         #05  pc 00004432  /system/lib/libwimax_jni.so
         #06  pc 00011e74  /system/lib/libdvm.so
         #07  pc 0004354a  /system/lib/libdvm.so
         #08  pc 00017088  /system/lib/libdvm.so
         #09  pc 0001c210  /system/lib/libdvm.so
         #10  pc 0001b0f8  /system/lib/libdvm.so
         #11  pc 00059c24  /system/lib/libdvm.so
         #12  pc 00059e3c  /system/lib/libdvm.so
         #13  pc 0004e19e  /system/lib/libdvm.so
         #14  pc 00011b94  /system/lib/libc.so
         #15  pc 0001173c  /system/lib/libc.so

code around pc:
ad115e9c 4620eddc bf00bd70 0001736e 0001734e 
ad115eac 4605b570 447c4c0a f7f44620 e006edc8 
ad115ebc 42ab68e3 68a0d103 f7f42122 6864edd2 
ad115ecc d1f52c00 44784803 edbef7f4 bf00bd70 
ad115edc 00017332 00017312 2100b51f 46682210 

code around lr:
afd110e8 e2166903 1a000018 e5945000 e1a02004 
afd110f8 e2055a02 e1a00005 e3851001 ebffed92 
afd11108 e3500000 13856002 1a000001 ea000009 
afd11118 ebfffe50 e1a01004 e1a00006 ebffed92 
afd11128 e1a01005 e1550000 e1a02006 e3a03000 

stack:
    4b857b10  40e43be8  
    4b857b14  00857280  
    4b857b18  00000000  
    4b857b1c  034e8968  
    4b857b20  ad118ce9  /system/lib/libnativehelper.so
    4b857b24  00000002  
    4b857b28  00000406

Sau đó, sử dụng addr2linetiện ích (tìm nó trong chuỗi công cụ NDK của bạn) để tìm chức năng gặp sự cố. Trong mẫu này, bạn làm

addr2line -e -f libc.so 0001173c

Và bạn sẽ thấy nơi bạn gặp vấn đề. Tất nhiên điều này sẽ không giúp bạn vì nó là trong libc.

Vì vậy, bạn có thể kết hợp các tiện ích của arm-eabi-objdumpđể tìm mục tiêu cuối cùng.

Hãy tin tôi, đó là một nhiệm vụ khó khăn.

Chỉ cần một bản cập nhật. Tôi nghĩ rằng tôi đã thực hiện xây dựng bản địa Android từ toàn bộ cây nguồn trong một thời gian khá dài, cho đến hôm nay tôi đã tự mình đọc kỹ các tài liệu NDK. Kể từ khi phát hành NDK-r6, nó đã cung cấp một tiện ích được gọi là ndk-stack.

Sau đây là nội dung từ các tài liệu NDK chính thức với bóng tar NDK-r9.

Tổng quat:

ndk-stack là một công cụ đơn giản cho phép bạn lọc các dấu vết ngăn xếp khi chúng xuất hiện trong đầu ra của 'adb logcat' và thay thế bất kỳ địa chỉ nào trong thư viện dùng chung bằng các giá trị: tương ứng.

Tóm lại, nó sẽ dịch một cái gì đó như:

  I/DEBUG   (   31): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
  I/DEBUG   (   31): Build fingerprint: 'generic/google_sdk/generic/:2.2/FRF91/43546:eng/test-keys'
  I/DEBUG   (   31): pid: 351, tid: 351  %gt;%gt;%gt; /data/local/ndk-tests/crasher <<<
  I/DEBUG   (   31): signal 11 (SIGSEGV), fault addr 0d9f00d8
  I/DEBUG   (   31):  r0 0000af88  r1 0000a008  r2 baadf00d  r3 0d9f00d8
  I/DEBUG   (   31):  r4 00000004  r5 0000a008  r6 0000af88  r7 00013c44
  I/DEBUG   (   31):  r8 00000000  r9 00000000  10 00000000  fp 00000000
  I/DEBUG   (   31):  ip 0000959c  sp be956cc8  lr 00008403  pc 0000841e  cpsr 60000030
  I/DEBUG   (   31):          #00  pc 0000841e  /data/local/ndk-tests/crasher
  I/DEBUG   (   31):          #01  pc 000083fe  /data/local/ndk-tests/crasher
  I/DEBUG   (   31):          #02  pc 000083f6  /data/local/ndk-tests/crasher
  I/DEBUG   (   31):          #03  pc 000191ac  /system/lib/libc.so
  I/DEBUG   (   31):          #04  pc 000083ea  /data/local/ndk-tests/crasher
  I/DEBUG   (   31):          #05  pc 00008458  /data/local/ndk-tests/crasher
  I/DEBUG   (   31):          #06  pc 0000d362  /system/lib/libc.so
  I/DEBUG   (   31):

Vào đầu ra dễ đọc hơn:

  ********** Crash dump: **********
  Build fingerprint: 'generic/google_sdk/generic/:2.2/FRF91/43546:eng/test-keys'
  pid: 351, tid: 351  >>> /data/local/ndk-tests/crasher <<<
  signal 11 (SIGSEGV), fault addr 0d9f00d8
  Stack frame #00  pc 0000841e  /data/local/ndk-tests/crasher : Routine zoo in /tmp/foo/crasher/jni/zoo.c:13
  Stack frame #01  pc 000083fe  /data/local/ndk-tests/crasher : Routine bar in /tmp/foo/crasher/jni/bar.c:5
  Stack frame #02  pc 000083f6  /data/local/ndk-tests/crasher : Routine my_comparison in /tmp/foo/crasher/jni/foo.c:9
  Stack frame #03  pc 000191ac  /system/lib/libc.so
  Stack frame #04  pc 000083ea  /data/local/ndk-tests/crasher : Routine foo in /tmp/foo/crasher/jni/foo.c:14
  Stack frame #05  pc 00008458  /data/local/ndk-tests/crasher : Routine main in /tmp/foo/crasher/jni/main.c:19
  Stack frame #06  pc 0000d362  /system/lib/libc.so

Sử dụng:

Để làm điều này, trước tiên bạn sẽ cần một thư mục chứa các phiên bản tượng trưng của các thư viện dùng chung của ứng dụng. Nếu bạn sử dụng hệ thống xây dựng NDK (tức là ndk-build), thì các hệ thống này luôn được đặt dưới $ PRO DỰ_PATH / obj / local /, trong đó viết tắt của ABI của thiết bị của bạn (nghĩa là armeabitheo mặc định).

Bạn có thể cung cấp logcatvăn bản dưới dạng đầu vào trực tiếp cho chương trình, ví dụ:

adb logcat | $NDK/ndk-stack -sym $PROJECT_PATH/obj/local/armeabi

Hoặc bạn có thể sử dụng tùy chọn -dump để chỉ định logcat dưới dạng tệp đầu vào, ví dụ:

adb logcat > /tmp/foo.txt
$NDK/ndk-stack -sym $PROJECT_PATH/obj/local/armeabi -dump foo.txt

QUAN TRỌNG :

Công cụ tìm kiếm dòng ban đầu chứa bắt đầu ở logcatđầu ra, tức là một cái gì đó trông giống như:

 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***

Khi sao chép / dán dấu vết, đừng quên dòng này từ dấu vết, hoặc ndk-stacksẽ không hoạt động chính xác.

LÀM:

Một phiên bản trong tương lai ndk-stacksẽ cố gắng khởi chạy adb logcatvà chọn đường dẫn thư viện tự động. Hiện tại, bạn sẽ phải thực hiện các bước này một cách thủ công.

Hiện tại, ndk-stackkhông xử lý các thư viện không có thông tin gỡ lỗi trong đó. Có thể hữu ích khi cố gắng phát hiện điểm nhập chức năng gần nhất đến một địa chỉ PC nhất định (ví dụ như trong ví dụ libc.so ở trên).

ĐỒNG Ý! Tôi thực sự xin lỗi những người đã thực sự gửi bình luận và câu trả lời, nhưng tôi đã tìm thấy vấn đề. Tôi không nghĩ rằng điều này sẽ giúp nhiều người khác cố gắng theo dõi SIGSEGV cá nhân của họ, nhưng của tôi (và nó rất khó) hoàn toàn liên quan đến điều này:

https://code.google.com.vn/p/android/issues/detail?id=8709

Libcrypto.so trong loại kết xuất của tôi đã đeo bám tôi. Tôi thực hiện băm MD5 dữ liệu gói khi cố gắng xác định xem tôi đã xem gói chưa và bỏ qua nếu tôi có. Tôi đã nghĩ tại một thời điểm đây là một vấn đề luồng xấu xí liên quan đến việc theo dõi các băm đó, nhưng hóa ra đó là lớp java.security.MessageDigest! Nó không phải là chủ đề an toàn!

Tôi đã tráo đổi nó với một UID mà tôi đang nhồi vào mỗi gói dựa trên UUID của thiết bị và dấu thời gian. Không có vấn đề gì kể từ đó.

Tôi đoán bài học tôi có thể truyền đạt cho những người trong tình huống của tôi là, ngay cả khi bạn là ứng dụng Java 100%, hãy chú ý đến thư viện gốc và biểu tượng được ghi chú trong kết xuất sự cố để tìm manh mối. Googling cho SIGSEGV + tên lib .so sẽ đi xa hơn nhiều so với mã vô dụng = 1, v.v ... Tiếp theo hãy nghĩ về nơi ứng dụng Java của bạn có thể chạm vào mã gốc, ngay cả khi bạn không làm gì. Tôi đã phạm sai lầm khi cho rằng đó là sự cố phân luồng Dịch vụ + Giao diện người dùng trong đó Canvas đang vẽ một thứ gì đó không có giá trị (trường hợp phổ biến nhất mà tôi đã viết trên SIGSEGV) và bỏ qua khả năng nó có thể hoàn toàn liên quan đến mã tôi đã viết liên quan đến lib .so trong bãi chứa sự cố. Đương nhiên java.security sẽ sử dụng một thành phần gốc trong libcrypto.so cho tốc độ, vì vậy một khi tôi đã tham gia, tôi đã tìm kiếm trên Android + SIGSEGV + libcrypto. vì vậy và tìm thấy các vấn đề tài liệu. Chúc may mắn!

Tôi đã nhận được lỗi này bằng cách lưu một đối tượng vào các tùy chọn được chia sẻ dưới dạng chuỗi chuyển đổi gson. Chuỗi gson không tốt, do đó, việc truy xuất và giải tuần tự hóa đối tượng không thực sự hoạt động chính xác. Điều này có nghĩa là bất kỳ lần truy cập tiếp theo nào vào đối tượng đều dẫn đến lỗi này. Đáng sợ :)

Tôi cũng đã nhận được lỗi này nhiều lần và tôi đã giải quyết nó. Lỗi này sẽ phải đối mặt trong trường hợp quản lý bộ nhớ ở phía bản địa.

Ứng dụng của bạn đang truy cập bộ nhớ ngoài không gian địa chỉ của nó. Đây rất có thể là một truy cập con trỏ không hợp lệ. SIGSEGV = lỗi phân đoạn trong mã gốc. Vì nó không xảy ra trong mã Java, bạn sẽ không thấy dấu vết ngăn xếp với các chi tiết. Tuy nhiên, bạn vẫn có thể thấy một số thông tin theo dõi ngăn xếp trong logcat nếu bạn nhìn xung quanh một chút sau khi quá trình ứng dụng gặp sự cố. Nó sẽ không cho bạn biết số dòng trong tệp, nhưng sẽ cho bạn biết các tệp và địa chỉ đối tượng nào được sử dụng trong chuỗi cuộc gọi. Từ đó bạn thường có thể tìm ra khu vực nào của mã có vấn đề. Bạn cũng có thể thiết lập kết nối gốc gdb cho quy trình đích và bắt nó trong trình gỡ lỗi.

Hôm nay tôi phải đối mặt với Fatal signal 11 (SIGSEGV), code 1, fault addr 0x8 in tid 18161vấn đề và tôi đấu tranh nửa ngày để giải quyết điều này.

Tôi đã thử nhiều thứ xóa bộ nhớ cache và xóa tập tin .gradle và tất cả.

Cuối cùng tôi disable Instant Runvà bây giờ tôi không gặp vấn đề này nữa. Bây giờ ứng dụng của tôi đang hoạt động sau khi cho phép chạy ngay lập tức. Đó có thể là sự cố chạy tức thời, Thử tắt và bật tính năng chạy tức thì

Từ câu trả lời này :

Chuyển đến Cài đặt hoặc Tùy chọn Android Studio (cho MAC) -> Xây dựng, Thực thi, Triển khai -> Chạy ngay lập tức.

Sau đó bỏ chọn hộp kiểm "Bật chạy ngay lập tức" ở trên cùng.

Hãy thử vô hiệu hóa khả năng tăng tốc phần cứng của Android trong bảng kê khai của bạn.

android:hardwareAccelerated="false"

Tôi đã gặp phải lỗi này khi tôi cố truy cập vào 'khung vẽ' bên ngoài onDraw()

    private Canvas canvas;

    @Override
    protected void onDraw(Canvas canvas) {
        this.canvas = canvas;
        ....... }

    private class ScaleListener extends ScaleGestureDetector.SimpleOnScaleGestureListener {
        @Override
        public boolean onScale(ScaleGestureDetector detector) { 
            canvas.save(); // here

Một thực tế rất xấu: /

Tôi đã gặp lỗi này khi sử dụng một bitmap như thế này:

bmp = BitmapFactory.decodeResource(this.getResources(), R.drawable.myBitMap);

Điều đã khắc phục vấn đề đối với tôi là giảm kích thước của bitmap (cao 1000px xuống 700px).

Tôi đã phải đối mặt với SIGSEGV trên Android 4.4.4 (Nexuses, Samsung) Và hóa ra lỗi nghiêm trọng là do phân tích cú pháp null Stringbằng cách sử dụngDecimalFormat

 static DecimalFormat decimalFormat = new DecimalFormat("###,###.###");
 void someMethod(String value) {
...
    Number number = decimalFormat.parse(value);//value is null, SIGSEGV will happen`
...
}

Trên Android> 21, nó đã được xử lý thành công với thử / bắt

Tôi đã đối mặt với vấn đề này ngay lúc trước, sau khi chuyển từ android.supportsang androidx.

Vấn đề là renderscript.

Giải pháp: Tôi đã xóa khỏi build.gradlehai dòng đó:

renderscriptTargetApi 21
renderscriptSupportModeEnabled true

sau khi xây dựng dự án thất bại, vì các tài liệu tham khảo chưa được giải quyết:

import androidx.renderscript.Allocation;
import androidx.renderscript.Element;
import androidx.renderscript.RenderScript;
import androidx.renderscript.ScriptIntrinsicBlur;

Vì vậy, tôi đã thay đổi chúng thành:

import android.renderscript.Allocation;
import android.renderscript.Element;
import android.renderscript.RenderScript;
import android.renderscript.ScriptIntrinsicBlur;

Sau đó, mọi vấn đề đã biến mất.

Nếu bạn đang sử dụng thư viện vitamio và lỗi nghiêm trọng này xảy ra.

Sau đó, đảm bảo rằng trong lớp dự án của bạn targetSdkVersion phải nhỏ hơn 23.

cảm ơn.

Trong trường hợp của tôi (tôi đang sử dụng Biểu mẫu Xamarin), lỗi này đã bị ném do lỗi liên kết - ví dụ:

<Label Grid.Column="4" Grid.Row="1" VerticalTextAlignment="Start" HorizontalTextAlignment="Center"  VerticalOptions="Start" HorizontalOptions="Start" FontSize="10" TextColor="Pink" Text="{Binding }"></Label>

Về cơ bản tôi đã xóa thuộc tính mô hình xem do nhầm lẫn. Đối với các nhà phát triển Xamarin, nếu bạn gặp vấn đề tương tự, hãy kiểm tra các ràng buộc của bạn ...

Nếu bạn đã thêm một số mã C gốc trong dự án của mình, câu trả lời này có thể hữu ích.

Tôi đã thêm một số mã C gốc trong dự án Android.

Bây giờ tôi đã cố gắng truy cập mã đã trả về chuỗi gốc cho tôi, trước khi xử lý chuỗi tôi đã đặt giá trị mặc định của nó là nullptr. Bây giờ khi lấy giá trị của nó trong mã java đã gặp phải vấn đề này.

Vì mã C gốc của chúng tôi nằm ngoài thư mục java, do đó, không có manh mối nào về dòng mã chính xác đang tạo ra vấn đề. Vì vậy, tôi sẽ đề nghị bạn kiểm tra tệp .cpp của bạn và cố gắng tìm bất kỳ manh mối nào ở đó.

Hy vọng như vậy bạn sẽ thoát khỏi vấn đề sớm. :)

Trong trường hợp của tôi, sự cố đã được gây ra bởi Android Profiler. Trong Android Studio, nhấp vào "Android Profiler" và "phiên kết thúc".

Trớ trêu thay, nó cũng gây ra các vấn đề hiệu năng cực đoan trong ứng dụng.

Thêm hai dòng này vào build.gradle của bạn trong phần android:

android{
    compileOptions {
            sourceCompatibility 1.8
            targetCompatibility 1.8
        }
}

Kiểm tra JNI / mã gốc của bạn. Một trong những tài liệu tham khảo của tôi là null, nhưng nó không liên tục, vì vậy nó không rõ ràng.

kiểm tra các hàm riêng của bạn, xem nó có trả về đúng hay không, nếu nó không được trả về, vui lòng thêm các câu trả về.

Đối với tôi vấn đề đó là do diễn viên xấu giữa hai hoạt động. Gần đây tôi đã chuyển phương thức này từ Activity1 sang phương thức khác 2. Làm như vậy, bộ tái cấu trúc đã bỏ biểu diễn rõ ràng này như trước đây. Vì vậy, thay vì làm

((Activity1) mainActivity).hideDialog();

tôi đã phải làm

((Activity2) mainActivity).hideDialog();

Lưu ý: Nhưng lỗi này không xảy ra trên Android 8.0 Tôi vẫn chưa biết tại sao.

*** Hy vọng nó giúp.

Tôi gặp lỗi lỗi phân đoạn này vì vấn đề Bộ nhớ . Cấu trúc của tôi có nhiều biến và mảng, có Mảng kích thước 1024.

Giảm kích thước xuống 512, lỗi đã biến mất.

PS: Đây là một cách giải quyết và không phải là một giải pháp. Cần phải tìm kích thước cấu trúc và phân bổ bộ nhớ động là một lựa chọn tốt hơn.

Tôi đã gặp lỗi này khi tôi sử dụng onDraw()chức năng ViewTreeObserver bên trong .

@Override
protected void onDraw(Canvas canvas) {
    // super.onDraw(canvas);
    ViewTreeObserver vto = mTextView.getViewTreeObserver();
    vto.addOnGlobalLayoutListener(new ViewTreeObserver.OnGlobalLayoutListener() {
        @Override
        public void onGlobalLayout() {
            // some animation        
        }
    });
 }

Tôi gặp vấn đề này với một gói đã được thêm vào ứng dụng của tôi (FancyShowCaseView) và gây ra sự cố này trên pre-lolipop. gói đó được viết bằng kotlin và mã chính của tôi được viết bằng java. vì vậy bây giờ tôi đang kiểm tra phiên bản trong pre-lolipop và đừng để lớp của nó được thực thi. tạm thời giải quyết vấn đề. kiểm tra xem nếu bạn có vấn đề tương tự như tôi

Tạo dấu vân tay: 'motorola / harpia / harpia: 6.0.1 / MPIS24.241-2.50-16 / 16: user / release-key' Sửa đổi: 'p1b0' ABI: 'arm' pid: 18139, tid: 25935, name: GLThread 2137 >>> com.portable3d.okt.a3dmap1 <<< tín hiệu 11 (SIGSEGV), mã 2 (SEGV_ACCERR), lỗi addr 0x7452f000

2 trong số 12 điện thoại bị lỗi, nhận thấy sự cố nằm ở onDrawFrame (), một số đối tượng là null, tôi không biết tại sao, tôi chỉ đặt

if(gears==null) return;.

Tôi gặp vấn đề khi tạo PDF bằng API PDF của Android và tôi vô tình sử dụng canvas.save () và canvas.restore () sau khi tôi đóng trang pdf.