我一直在阅读有关追踪SIGSEGVAndroid应用程序的原因的其他帖子.我打算在我的应用程序中搜索与Canvas使用相关的可能的NullPointers,但我的SIGSEGVbarf每次都有不同的内存地址.另外我见过code=1和code=2.如果内存地址是0x00000000,我有一个线索它是一个NullPointer.
我得到的最后一个是code=2:
A/libc(4969): Fatal signal 11 (SIGSEGV) at 0x42a637d9 (code=2)
有关如何追踪此问题的任何建议？
我有一个嫌疑人,但我还没有热衷于尝试它.我的应用程序使用OSMDroid API进行离线映射.OverlayItem类表示地图上的标记/节点.我有一个服务,它通过网络收集数据以填充OverlayItem,然后显示在地图上.为了简化我的设计,我将OverlayItem扩展到我自己的NodeOverlayItem类中,该类包含我在UI Activity和Service中使用的一些附加属性.这给了我UI和服务的单点项目信息.我使用Intents广播到Activity,以便在更改内容时刷新UI映射.Activity绑定到Service,并且有一个Service方法来获取NodeOverlayItem的列表.我认为可能是OSMDroid API使用OverlayItem,而我的服务同时更新节点信息.(并发问题)
在我写这篇文章时,我认为这确实是问题所在.令人头疼的是没有从NodeOverlayItem拆分Node和OverlayItem,而是Activity需要来自Node的一些数据,服务保存.另外,当创建Activity(onResume等等)时,需要从活动离开时服务一直维护的Node数据重新创建OverlayItem对象.例如,您启动应用程序,服务收集数据,UI显示数据,您转到主页,然后返回应用程序,活动将需要从最新的服务节点数据中提取并重新创建OverlayItem.
我知道这不是一个很好或明确的问题.这就像我所有的SO问题都是利基或模糊.如果有人对如何解释这些SIGSEGV错误有任何建议,我们将不胜感激!
更新 这是调试会话期间捕获的最新崩溃.我有3个这样的设备用于测试,当我开发和测试时,它们并不都可靠地崩溃.我添加了一些额外的内容,因此可以注意到GC日志记录.您可以看到问题可能与内存耗尽无关.
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% …