Android的致命信号11（SIGSEGV）在0x636f7d89（code = 1）。怎样才可以追查？ [英] Android Fatal signal 11 (SIGSEGV) at 0x636f7d89 (code=1). How can it be tracked down?
问题描述
我一直在阅读上跟踪下来的原因在一个Android应用程序得到一个 SIGSEGV 其他职位。我打算冲刷我的应用程序的相关画布使用可能NullPointers，但我的 SIGSEGV 每次barfs了不同的内存地址。另外，我已经看到了 code = 1 和 code = 2 。如果内存地址是 00000000 ，我有一个线索，这是一个空指针。
最后一个我得到的是一个 code = 2 ：
A / libc的（4969）：致命的信号11（SIGSEGV）在0x42a637d9（code = 2）
如何跟踪下来？任何建议
我有一个犯罪嫌疑人，但我并不热衷于用它进行试验呢。我的应用程序使用的离线映射OSMDroid API。地图上的OverlayItem类重新presents标记/节点。我有一个服务是经由网络收集数据来填充OverlayItem其然后在地图上显示。在努力简化我的设计，我扩展OverlayItem到我自己的NodeOverlayItem类，其中包括一些另外的属性我在UI活动和服务使用。这给了我一个单点的项目信息的用户界面和服务。我曾经意图广播到活动刷新UI映射时，事情发生了转变。该活动绑定到服务，并有一个服务方法来获得NodeOverlayItem的名单。我想可能是OSMDroid API的使用OverlayItem，并在同一时间我的服务更新节点信息。 （并发问题）
在我写这篇文章，我认为这是真正的问题。头痛是不是分裂出来的节点和OverlayItem从NodeOverlayItem，这是该活动将从节点需要一些数据，该服务拥有。另外在创建活动时（onResume，等...）的OverlayItem对象将需要从节点的数据重新创建的服务一直保持该项活动是去的。例如你启动应用程序，该服务将收集的数据，用户界面显示它，你到首页，然后再返回到应用程序，该活动将需要拉并重新创建OverlayItem的从最新的服务节点的数据。
我知道这是不是一个伟大的和明确的问题。这就像我的一切都那么问题是利基或含糊不清。如果任何人有关于如何跨preT那些 SIGSEGV 错误，那将是极大的AP preciated建议！
更新 这里有一个调试会话期间捕获最新的崩溃。我有3个，这些设备被用于测试和他们并不都可靠地崩溃的时候我正在开发和测试。我包括一些额外的只是这样的GC日志可以注意。你可以看到这个问题可能是不相关的内存耗尽。
2月3日至3日：02：38.328：I / CommService（7477）：收到的报文：192.168.1.102
二月三号至3日：02：38.328：I / CommService（7477）：已处理这个包。这是一个重新广播从另一个节点，或者从我自己。这不是一个重复播放，但。
二月三号至3日：02：38.406：D / CommService（7477）：检查OLSRd信息...
二月三号至3日：02：38.460：D / CommService（7477）：监测节点...
二月三号至3日：02：38.515：D / dalvikvm（7477）：GC_CONCURRENT释放2050K，免费16％17151K / 20359K，暂停为3ms + 6ms的
二月三号至3日：02：38.515：I / CommService（7477）：收到的报文：192.168.1.102
3月3号02：02：38.515：D / CommService（7477）：转发分组（4f68802cf10684a83ac4936ebb3c934d）沿着到其他节点。
二月三号至3日：02：38.609：I / CommService（7477）：收到的报文：192.168.1.100
3月3号02：02：38.609：D / CommService（7477）：转发分组（e4bc81e91ec92d06f83e03068f52ab4）沿着到其他节点。
二月三号至3日：02：38.609：D / CommService（7477）：已处理此数据包：4204a5b27745ffe5e4f8458e227044bf
二月三号至3日：02：38.609：A / libc的（7477）：致命的信号11（SIGSEGV）在0x68f52abc（code = 1）
二月三号至3日：02：38.914：I / DEBUG（4008）：*** *** *** *** *** *** *** *** *** *** *** * ** *** *** *** ***
二月三号至3日：02：38.914：I / DEBUG（4008）：建立指纹：联想/ IdeaTab_A1107 / A1107：4.0.4 / MR1 / eng.user.20120719.150703：用户/释放键
二月三号至3日：02：38.914：I / DEBUG（4008）：PID：7477，TID：7712＆GT;＆GT;＆GT; com.test.testm＆LT;＆LT;＆LT;
二月三号至3日：02：38.914：I / DEBUG（4008）：11（SIGSEGV），code 1（SEGV_MAPERR），故障地址68f52abc
二月三号至3日：02：38.914：I / DEBUG（4008）：R0 68f52ab4 R1 412ef268 R2 4d9c3bf4 R3 412ef268
二月三号至3日：02：38.914：I / DEBUG（4008）：R4 001ad8f8 R5 4d9c3bf4 R6 412ef268 R7 4c479df8
二月三号至3日：02：38.914：I / DEBUG（4008）：R8 4d9c3c0c R9 4c479dec 10 46cf260a FP 4d9c3c24
二月三号至3日：02：38.914：I / DEBUG（4008）：IP 40262a04 SP 4d9c3bc8 LR 402d01dd PC 402d0182 CPSR 00000030
二月三号至3日：02：38.914：I / DEBUG（4008）：D0 00000001000c0102 D1 3a22364574614c7d
二月三号至3日：02：38.914：I / DEBUG（4008）：D2 D3 403fc0000000007d 363737343433350a
二月三号至3日：02：38.914：I / DEBUG（4008）：D4 49544341223a2273 D5 6f6567222c224556
二月三号至3日：02：38.914：I / DEBUG（4008）：D6 D7 3a223645676e6f4c 000000013835372d
二月三号至3日：02：38.914：I / DEBUG（4008）：0000000000000000 D8 D9 40400000亿
二月三号至3日：02：38.914：I / DEBUG（4008）：D10 D11 0000000000000000 40400000亿
二月三号至3日：02：38.914：I / DEBUG（4008）：D12 40400000亿D13 0000000000000021
二月三号至3日：02：38.914：I / DEBUG（4008）：D14 D15 0000000000000000 0000000000000000
二月三号至3日：02：38.914：I / DEBUG（4008）：D16 3fe62e42fefa39ef D17 3ff0000000000000
二月三号至3日：02：38.914：I / DEBUG（4008）：D18 3fe62e42fee00000 D19 0000000000000000
二月三号至3日：02：38.914：I / DEBUG（4008）：D20 0000000000000000 D21 3ff0000000000000
二月三号至3日：02：38.914：I / DEBUG（4008）：D22 40280000亿D23 3ff0000000000000
二月三号至3日：02：38.914：I / DEBUG（4008）：D24 0000000000000000 D25 3ff0000000000000
二月三号至3日：02：38.914：I / DEBUG（4008）：D26 D27 0000000000000000 c028000000000000
二月三号至3日：02：38.914：I / DEBUG（4008）：D28 D29 0000000000000000 3ff0000000000000
二月三号至3日：02：38.914：I / DEBUG（4008）：D30 3ff0000000000000 D31 3fecccccb5c28f6e
二月三号至3日：02：38.914：I / DEBUG（4008）：SCR 60000013
二月三号至3日：02：39.046：I / DEBUG（4008）：＃00件0006b182 /system/lib/libcrypto.so（EVP_DigestFinal_ex）
二月三号至3日：02：39.046：I / DEBUG（4008）：＃01件0006b1d8 /system/lib/libcrypto.so（EVP_DigestFinal）
二月三号至3日：02：39.054：I / DEBUG（4008）：＃02件0001f814 /system/lib/libnativehelper.so
二月三号至3日：02：39.054：I / DEBUG（4008）：＃03件0001ec30 /system/lib/libdvm.so（dvmPlatformInvoke）
二月三号至3日：02：39.054：I / DEBUG（4008）：＃04件00058c70 /system/lib/libdvm.so（_Z16dvmCallJNIMethodPKjP6JValuePK6MethodP6Thread）
二月三号至3日：02：39.054：I / DEBUG（4008）：围绕PC code：
二月三号至3日：02：39.054：I / DEBUG（4008）：402d0160 0003151e 4604b570 f7ff460d 4620ff81 .... p..FF ... F
二月三号至3日：02：39.054：I / DEBUG（4008）：402d0170 f7ff4629 bd70ff93 4604b570 460e6800）F .... pp.FhF
二月三号至3日：02：39.054：I / DEBUG（4008）：402d0180 68834615 dd062b40 21fa4810 44784a10 .Fh @ + ... H金星！。
二月三号至3日：02：39.054：I / DEBUG（4008）：402d0190 f7c8447a 6821f80f 698a4620 47904631 ZD .... ^ h F.i1F.G
二月三号至3日：02：39.054：I / DEBUG（4008）：402d01a0 b1154606 68836820 6822602b b12b6a13 .F .. H.H +`h.j +。
二月三号至3日：02：39.054：I / DEBUG（4008）：约LR code：
二月三号至3日：02：39.054：I / DEBUG（4008）：！。！402d01bc 68e06821 21006c4a ea0af7c4 bd704630 h.hJl .... 0Fp。
二月三号至3日：02：39.054：I / DEBUG（4008）：402d01cc 00031492 000314b5 4604b570 ffcef7ff ........ p..F ....
二月三号至3日：02：39.054：I / DEBUG（4008）：402d01dc 46204605 ff12f7ff bd704628 4604b573 .F˚F....（Fp.s..F
二月三号至3日：02：39.054：I / DEBUG（4008）：！402d01ec 2102460d fb36f002 42ab6823 b123d020 .F。6＃为hB＃。
二月三号至3日：02：39.054：I / DEBUG（4008）：402d01fc b1136c5b f7c868e0 68a0fccf 05c26025并[... H ..... H％`..
二月三号至3日：02：39.054：I / DEBUG（4008）：约地址68f52abc内存映射：
二月三号至3日：02：39.054：I / DEBUG（4008）：4d8c5000-4d9c4000
二月三号至3日：02：39.054：I / DEBUG（4008）：（没有地图的地址）
二月三号至3日：02：39.054：I / DEBUG（4008）：b0001000-b0009000 /系统/斌/连接器
二月三号至3日：02：39.054：I / DEBUG（4008）：堆栈：
二月三号至3日：02：39.054：I / DEBUG（4008）：4d9c3b88 408d1f90 /system/lib/libdvm.so
二月三号至3日：02：39.054：I / DEBUG（4008）：4d9c3b8c 412ef258的/ dev / ashmem / Dalvik的堆（删除）
二月三号至3日：02：39.054：I / DEBUG（4008）：4d9c3b90 00000001
二月三号至3日：02：39.054：I / DEBUG（4008）：4d9c3b94 408d6c58 /system/lib/libdvm.so
二月三号至3日：02：39.054：I / DEBUG（4008）：4d9c3b98 408d6fa8 /system/lib/libdvm.so
二月三号至3日：02：39.054：I / DEBUG（4008）：4d9c3b9c 4c479dec
二月三号至3日：02：39.054：I / DEBUG（4008）：4d9c3ba0 46cf260a /system/framework/core.odex
二月三号至3日：02：39.054：I / DEBUG（4008）：4d9c3ba4 408735e7 /system/lib/libdvm.so
二月三号至3日：02：39.054：I / DEBUG（4008）：4d9c3ba8 412ef258的/ dev / ashmem / Dalvik的堆（删除）
二月三号至3日：02：39.054：I / DEBUG（4008）：4d9c3bac 002bf070 [堆]
二月三号至3日：02：39.054：I / DEBUG（4008）：4d9c3bb0 412ef258的/ dev / ashmem / Dalvik的堆（删除）
二月三号至3日：02：39.054：I / DEBUG（4008）：4d9c3bb4 00000000
二月三号至3日：02：39.054：I / DEBUG（4008）：4d9c3bb8 412ef268的/ dev / ashmem / Dalvik的堆（删除）
二月三号至3日：02：39.054：I / DEBUG（4008）：4d9c3bbc 00000000
二月三号至3日：02：39.054：I / DEBUG（4008）：4d9c3bc0 df0027ad
二月三号至3日：02：39.054：I / DEBUG（4008）：4d9c3bc4 00000000
二月三号至3日：02：39.054：I / DEBUG（4008）：＃00 4d9c3bc8 001ad8f8 [堆]
二月三号至3日：02：39.054：I / DEBUG（4008）：4d9c3bcc 002ae0b8 [堆]
二月三号至3日：02：39.054：I / DEBUG（4008）：4d9c3bd0 00000004
二月三号至3日：02：39.054：I / DEBUG（4008）：4d9c3bd4 402d01dd /system/lib/libcrypto.so
二月三号至3日：02：39.054：I / DEBUG（4008）：＃01 4d9c3bd8 001ad8f8 [堆]
二月三号至3日：02：39.054：I / DEBUG（4008）：4d9c3bdc 002ae0b8 [堆]
二月三号至3日：02：39.054：I / DEBUG（4008）：4d9c3be0 00000004
二月三号至3日：02：39.054：I / DEBUG（4008）：4d9c3be4 4024e817 /system/lib/libnativehelper.so
二月三号至3日：02：39.406：D / CommService（7477）：检查OLSRd信息...
二月三号至3日：02：39.500：D / CommService（7477）：监测节点...
二月三号至3日：02：39.500：D / dalvikvm（7477）：GC_FOR_ALLOC释放2073K，16％免费17118K / 20359K，暂停51ms
二月三号至3日：02：39.632：D / dalvikvm（7477）：GC_CONCURRENT释放1998K，免费16％17162K / 20359K，暂停2MS + 4ms的
二月三号至3日：02：40.406：D / CommService（7477）：检查OLSRd信息...
二月三号至3日：02：40.445：D / CommService（7477）：监测节点...
二月三号至3日：02：40.562：D / dalvikvm（7477）：GC_CONCURRENT释放2045K，免费16％17158K / 20359K，暂停3毫秒+ 4ms的
二月三号至3日：02：41.406：D / CommService（7477）：检查OLSRd信息...
二月三号至3日：02：41.445：D / CommService（7477）：监测节点...
二月三号至3日：02：41.531：D / dalvikvm（7477）：GC_CONCURRENT释放2045K，免费16％17154K / 20359K，暂停3毫秒+ 12毫秒
二月三号至3日：02：42.406：D / CommService（7477）：检查OLSRd信息...
二月三号至3日：02：42.445：D / CommService（7477）：监测节点...
二月三号至3日：02：42.507：D / dalvikvm（7477）：GC_CONCURRENT释放2068K，免费16％17128K / 20359K，暂停3毫秒+ 4ms的
二月三号至3日：02：42.679：D / dalvikvm（7477）：GC_CONCURRENT释放2006K，免费16％17161K / 20359K，暂停2MS + 12毫秒
二月三号至3日：02：43.140：I / BootReceiver（1236）：复制/数据/墓碑/ tombstone_05到DropBox的（SYSTEM_TOMBSTONE）
二月三号至3日：02：43.210：D / dalvikvm（1236）：GC_FOR_ALLOC释放912K，17％的自由10207K / 12295K，暂停62ms
二月三号至3日：02：43.265：D / dalvikvm（1236）：GC_FOR_ALLOC释放243K，16％免费10374K / 12295K，暂停49ms
二月三号至3日：02：43.265：I / dalvikvm堆（1236）：成长堆（破片的情况下），以10.507MB为196628字节分配
OK！我真的很抱歉给那些实际上已经提交了意见和答案，但我发现这个问题。我不认为这会帮助很多人试图追查他们的个人SIGSEGV的，但我（这是很困难的）完全是与此相关的：
HTTPS：//$c$c.google。 COM / P /安卓/问题/详细信息？ID = 8709
那种在我的垃圾堆里的libcrypto.so避让我，我做的数据包的MD5哈希值当试图确定是否我已经看到了包，并跳过它，如果我有。我想在一个点上，这是一个丑陋的线程问题涉及到跟踪这些哈希，但事实证明这是java.security.MessageDigest中的类！它不是线程安全的！
我换它与一个UID基于设备的UUID和时间戳在每一个数据包，我馅。没有问题，因为。
我想教训我可以传授给那些要在我的情况是，即使你是一个100％的Java应用程序，注重本地库和符号崩溃转储线索指出。谷歌搜索的SIGSEGV +的lib的.so域名将走的更远远比无用code = 1，等...下一页想想，你的Java应用能碰到本土code，即使它没有你做的事情。我做了假设它是一个服务+ UI线程问题，即在画布中画的东西，是空，（我用Google搜索上SIGSEGV最常见的情况）的错误，忽略了它本来可以完全与code口的可能性写道，是有关在崩溃转储的lib的.so。当然java.security中会使用原生组件libcrypto.so速度，所以一旦我避让的，我Google为Android + SIGSEGV + libcrypto.so，发现记录的问题。祝你好运！
I've been reading the other posts on tracking down the reasons for getting a SIGSEGV in an Android app. I plan to scour my app for possible NullPointers related to Canvas use, but my SIGSEGV barfs up a different memory address each time. Plus I've seen code=1 and code=2. If the memory address was 0x00000000, I'd have a clue it is a NullPointer.
The last one I got was a code=2:
A/libc(4969): Fatal signal 11 (SIGSEGV) at 0x42a637d9 (code=2)
Any suggestions on how to track this down?
I have a suspect, but I'm not keen on experimenting with it yet. My app uses the OSMDroid API for offline mapping. The OverlayItem class represents markers/nodes on the map. I have a Service that collects data via the network to populate the OverlayItem which are then displayed on the map. In an effort to simplify my design, I extended OverlayItem into my own NodeOverlayItem class, which includes some addition attributes I use in the UI Activity and in the Service. This gave me a single point of Item information for the UI and Service. I used Intents to broadcast to the Activity to refresh the UI map when something changed. The Activity binds to the Service and there's a Service method to get the list of NodeOverlayItem's. I think it might be the OSMDroid API's use of OverlayItem, and my Service updating node information at the same time. (a concurrency issue)
As I write this I think that's really the problem. The headache isn't splitting out the Node and OverlayItem from NodeOverlayItem, it's that the Activity will need some data from the Node, that the Service holds. Plus when the Activity is created (onResume, etc...) the OverlayItem objects will need to be re-created from the Node data that the Service has been maintaining while the Activity was away. e.g. You start the app, the Service collects data, the UI displays it, you go to Home, then back to the app, the Activity will need to pull and re-create the OverlayItem's from the latest Service node data.
I know this isn't a great or clear questions. It's like all my SO questions are niche or obscure. If anyone has a suggestion on how to interpret those SIGSEGV errors, it would be greatly appreciated!
UPDATE Here's the latest crash captured during a debug session. I have 3 of these devices being used for testing and they don't all crash reliably when I'm developing and testing. I included a bit extra just so the GC logging could be noted. You can see the problem is probably not related to memory exhaustion.
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
OK! I'm really sorry to those that have actually submitted comments and answers, but I found the problem. I don't think this will help a lot of others trying to track down their personal SIGSEGV, but mine (and it was very hard) was entirely related to this:
https://code.google.com/p/android/issues/detail?id=8709
The libcrypto.so in my dump kind of clued me in. I do a MD5 hash of packet data when trying to determine if I've already seen the packet, and skipping it if I had. I thought at one point this was an ugly threading issue related to tracking those hashes, but it turned out it was the java.security.MessageDigest class! It's not thread safe!
I swapped it out with a UID I was stuffing in every packet based on the device UUID and a timestamp. No problems since.
I guess the lesson I can impart to those that were in my situation is, even if you're a 100% Java application, pay attention to the native library and symbol noted in the crash dump for clues. Googling for SIGSEGV + the lib .so name will go a lot farther than the useless code=1, etc... Next think about where your Java app could touch native code, even if it's nothing you're doing. I made the mistake of assuming it was a Service + UI threading issue where the Canvas was drawing something that was null, (the most common case I Googled on SIGSEGV) and ignored the possibility it could have been completely related to code I wrote that was related to the lib .so in the crash dump. Naturally java.security would use a native component in libcrypto.so for speed, so once I clued in, I Googled for Android + SIGSEGV + libcrypto.so and found the documented issue. Good luck!
这篇关于Android的致命信号11（SIGSEGV）在0x636f7d89（code = 1）。怎样才可以追查？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
