为什么应用程序会随机崩溃？

Question

为什么应用程序会随机崩溃？

27

我正在开发一款音乐播放器应用程序。除了应用程序突然死亡外，一切都正常。有时候这种情况发生在应用程序启动后，有时候是在长时间运行后。有时候一切正常，应用程序没有崩溃。我观察日志以了解是什么原因导致应用程序崩溃，并找到了以下内容：

11-02 16:39:39.293: A/libc(3556): @@@ ABORTING: INVALID HEAP ADDRESS IN dlfree
11-02 16:39:39.293: A/libc(3556): Fatal signal 11 (SIGSEGV) at 0xdeadbaad (code=1)

以下是完整的日志，当应用程序崩溃时在logcat中找到的内容：

11-02 16:39:39.293: A/libc(3556): @@@ ABORTING: INVALID HEAP ADDRESS IN dlfree
11-02 16:39:39.293: A/libc(3556): Fatal signal 11 (SIGSEGV) at 0xdeadbaad (code=1)
11-02 16:39:39.793: I/DEBUG(3257): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
11-02 16:39:39.793: I/DEBUG(3257): Build fingerprint: 'Polaroid/nuclear_md7008/nuclear-md7008:4.0.4/IMM76D/20120929:eng/test-keys'
11-02 16:39:39.793: I/DEBUG(3257): pid: 3556, tid: 3556  >>> com.polaroid.kidsmusic <<<
11-02 16:39:39.793: I/DEBUG(3257): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr deadbaad
11-02 16:39:39.793: I/DEBUG(3257):  r0 deadbaad  r1 00000001  r2 40000000  r3 00000000
11-02 16:39:39.793: I/DEBUG(3257):  r4 00000000  r5 00000027  r6 400f4db0  r7 40103474
11-02 16:39:39.793: I/DEBUG(3257):  r8 021821c0  r9 40061840  10 00000008  fp beb666e4
11-02 16:39:39.793: I/DEBUG(3257):  ip ffffffff  sp beb66538  lr 400d5f71  pc 400d26d0  cpsr 60000030
11-02 16:39:39.793: I/DEBUG(3257):  d0  000001e000000000  d1  43f00000000001e0
11-02 16:39:39.793: I/DEBUG(3257):  d2  443f000000000000  d3  4a8688c00000004a
11-02 16:39:39.793: I/DEBUG(3257):  d4  3f800000020922a8  d5  0000000000000000
11-02 16:39:39.793: I/DEBUG(3257):  d6  0000000000000000  d7  0000000000000000
11-02 16:39:39.793: I/DEBUG(3257):  d8  0000000000000000  d9  43f0000000000000
11-02 16:39:39.793: I/DEBUG(3257):  d10 3fec2014384e6205  d11 0000000000000000
11-02 16:39:39.793: I/DEBUG(3257):  d12 0000000000000000  d13 0000000000000000
11-02 16:39:39.793: I/DEBUG(3257):  d14 0000000000000000  d15 0000000000000000
11-02 16:39:39.793: I/DEBUG(3257):  d16 0000000000000001  d17 3ff0000000000000
11-02 16:39:39.793: I/DEBUG(3257):  d18 3e56d3ae604f8858  d19 bfb0b3f66e58abf6
11-02 16:39:39.793: I/DEBUG(3257):  d20 4000000000000000  d21 3f1149926a1476f9
11-02 16:39:39.793: I/DEBUG(3257):  d22 bebba89f4215f5e0  d23 3fd5ce9e44d86000
11-02 16:39:39.793: I/DEBUG(3257):  d24 3e66376972bea4d0  d25 c014000000000000
11-02 16:39:39.793: I/DEBUG(3257):  d26 3ff5bf0a00000000  d27 bfb0b3f66e58abf8
11-02 16:39:39.793: I/DEBUG(3257):  d28 bffadb73617eb466  d29 3fd5ce9e5bac0e60
11-02 16:39:39.793: I/DEBUG(3257):  d30 3c7aa87621713b5a  d31 3e56d3ae60000000
11-02 16:39:39.793: I/DEBUG(3257):  scr 80000013
11-02 16:39:39.883: I/DEBUG(3257):          #00  pc 000176d0  /system/lib/libc.so
11-02 16:39:39.883: I/DEBUG(3257):          #01  pc 0001355a  /system/lib/libc.so
11-02 16:39:39.883: I/DEBUG(3257):          #02  pc 00015898  /system/lib/libc.so (dlfree)
11-02 16:39:39.883: I/DEBUG(3257):          #03  pc 00015f10  /system/lib/libc.so (free)
11-02 16:39:39.893: I/DEBUG(3257):          #04  pc 000009ac  /system/lib/libstdc++.so (_ZdlPvRKSt9nothrow_t)
11-02 16:39:39.893: I/DEBUG(3257):          #05  pc 0000bf94  /system/lib/libhwui.so
11-02 16:39:39.893: I/DEBUG(3257):          #06  pc 000104c0  /system/lib/libhwui.so (_ZN7android10uirenderer14OpenGLRenderer7prepareEb)
11-02 16:39:39.893: I/DEBUG(3257):          #07  pc 00055ec0  /system/lib/libandroid_runtime.so
11-02 16:39:39.893: I/DEBUG(3257):          #08  pc 0001ec30  /system/lib/libdvm.so (dvmPlatformInvoke)
11-02 16:39:39.893: I/DEBUG(3257):          #09  pc 00058c70  /system/lib/libdvm.so (_Z16dvmCallJNIMethodPKjP6JValuePK6MethodP6Thread)
11-02 16:39:39.893: I/DEBUG(3257): code around pc:
11-02 16:39:39.893: I/DEBUG(3257): 400d26b0 4623b15c 2c006824 e026d1fb b12368db  \.#F$h.,..&..h#.
11-02 16:39:39.893: I/DEBUG(3257): 400d26c0 21014a17 6011447a 48124798 24002527  .J.!zD.`.G.H'%.$
11-02 16:39:39.893: I/DEBUG(3257): 400d26d0 f7f47005 2106ef48 efe4f7f5 460aa901  .p..H..!.......F
11-02 16:39:39.893: I/DEBUG(3257): 400d26e0 f04f2006 94015380 94029303 eba0f7f5  . O..S..........
11-02 16:39:39.893: I/DEBUG(3257): 400d26f0 4622a905 f7f52002 f7f4ebaa 2106ef34  .."F. ......4..!
11-02 16:39:39.893: I/DEBUG(3257): code around lr:
11-02 16:39:39.893: I/DEBUG(3257): 400d5f50 41f0e92d 46804c0c 447c2600 68a56824  -..A.L.F.&|D$h.h
11-02 16:39:39.893: I/DEBUG(3257): 400d5f60 e0076867 300cf9b5 dd022b00 47c04628  gh.....0.+..(F.G
11-02 16:39:39.893: I/DEBUG(3257): 400d5f70 35544306 37fff117 6824d5f4 d1ee2c00  .CT5...7..$h.,..
11-02 16:39:39.893: I/DEBUG(3257): 400d5f80 e8bd4630 bf0081f0 0002858a 41f0e92d  0F..........-..A
11-02 16:39:39.893: I/DEBUG(3257): 400d5f90 fb01b086 9004f602 461f4815 4615460c  .........H.F.F.F
11-02 16:39:39.893: I/DEBUG(3257): memory map around addr deadbaad:
11-02 16:39:39.893: I/DEBUG(3257): beb46000-beb67000 [stack]
11-02 16:39:39.893: I/DEBUG(3257): (no map for address)
11-02 16:39:39.893: I/DEBUG(3257): ffff0000-ffff1000 [vectors]
11-02 16:39:39.893: I/DEBUG(3257): stack:
11-02 16:39:39.893: I/DEBUG(3257):     beb664f8  00000001  
11-02 16:39:39.893: I/DEBUG(3257):     beb664fc  beb66538  [stack]
11-02 16:39:39.903: I/DEBUG(3257):     beb66500  400fe778  /system/lib/libc.so
11-02 16:39:39.903: I/DEBUG(3257):     beb66504  0000000c  
11-02 16:39:39.903: I/DEBUG(3257):     beb66508  400fe70c  /system/lib/libc.so
11-02 16:39:39.903: I/DEBUG(3257):     beb6650c  40103808  
11-02 16:39:39.903: I/DEBUG(3257):     beb66510  00000000  
11-02 16:39:39.903: I/DEBUG(3257):     beb66514  400d5f71  /system/lib/libc.so
11-02 16:39:39.903: I/DEBUG(3257):     beb66518  00000000  
11-02 16:39:39.903: I/DEBUG(3257):     beb6651c  beb6654c  [stack]
11-02 16:39:39.903: I/DEBUG(3257):     beb66520  400f4db0  /system/lib/libc.so
11-02 16:39:39.903: I/DEBUG(3257):     beb66524  40103474  
11-02 16:39:39.903: I/DEBUG(3257):     beb66528  021821c0  [heap]
11-02 16:39:39.903: I/DEBUG(3257):     beb6652c  400d50dd  /system/lib/libc.so
11-02 16:39:39.903: I/DEBUG(3257):     beb66530  df0027ad  
11-02 16:39:39.903: I/DEBUG(3257):     beb66534  00000000  
11-02 16:39:39.903: I/DEBUG(3257): #00 beb66538  beb66534  [stack]
11-02 16:39:39.903: I/DEBUG(3257):     beb6653c  00000001  
11-02 16:39:39.903: I/DEBUG(3257):     beb66540  400f4d94  /system/lib/libc.so
11-02 16:39:39.903: I/DEBUG(3257):     beb66544  00000005  
11-02 16:39:39.903: I/DEBUG(3257):     beb66548  beb66564  [stack]
11-02 16:39:39.903: I/DEBUG(3257):     beb6654c  fffffbdf  
11-02 16:39:39.903: I/DEBUG(3257):     beb66550  beb66564  [stack]
11-02 16:39:39.903: I/DEBUG(3257):     beb66554  beb66564  [stack]
11-02 16:39:39.903: I/DEBUG(3257):     beb66558  400f82ec  /system/lib/libc.so
11-02 16:39:39.903: I/DEBUG(3257):     beb6655c  400ce55f  /system/lib/libc.so
11-02 16:39:39.903: I/DEBUG(3257): #01 beb66560  00000000  
11-02 16:39:39.903: I/DEBUG(3257):     beb66564  20404040  
11-02 16:39:39.903: I/DEBUG(3257):     beb66568  524f4241  
11-02 16:39:39.903: I/DEBUG(3257):     beb6656c  474e4954  /data/dalvik-cache/system@framework@framework.jar@classes.dex
11-02 16:39:39.903: I/DEBUG(3257):     beb66570  4e49203a  
11-02 16:39:39.903: I/DEBUG(3257):     beb66574  494c4156  /system/lib/libbcc.so
11-02 16:39:39.903: I/DEBUG(3257):     beb66578  45482044  /dev/ashmem/dalvik-mark-stack (deleted)
11-02 16:39:39.903: I/DEBUG(3257):     beb6657c  41205041  /dev/ashmem/dalvik-heap (deleted)
11-02 16:39:39.903: I/DEBUG(3257):     beb66580  45524444  /dev/ashmem/dalvik-mark-stack (deleted)
11-02 16:39:39.903: I/DEBUG(3257):     beb66584  49205353  /system/lib/libbcc.so
11-02 16:39:39.903: I/DEBUG(3257):     beb66588  6c64204e  
11-02 16:39:39.903: I/DEBUG(3257):     beb6658c  65657266  
11-02 16:39:39.903: I/DEBUG(3257):     beb66590  02079100  [heap]
11-02 16:39:39.903: I/DEBUG(3257):     beb66594  40103498  
11-02 16:39:39.903: I/DEBUG(3257):     beb66598  00000000  
11-02 16:39:39.903: I/DEBUG(3257):     beb6659c  400cfa4d  /system/lib/libc.so
11-02 16:39:39.903: I/DEBUG(3257):     beb665a0  021800a8  [heap]
11-02 16:39:39.903: I/DEBUG(3257):     beb665a4  401034e0  
11-02 16:39:39.903: I/DEBUG(3257):     beb665a8  0202ed20  [heap]
11-02 16:39:39.903: I/DEBUG(3257):     beb665ac  0202ed60  [heap]
11-02 16:39:39.903: I/DEBUG(3257):     beb665b0  beb666d0  [stack]
11-02 16:39:39.903: I/DEBUG(3257):     beb665b4  40103498  
11-02 16:39:39.903: I/DEBUG(3257):     beb665b8  47821416  /data/dalvik-cache/system@framework@framework.jar@classes.dex
11-02 16:39:39.903: I/DEBUG(3257):     beb665bc  400cfa4d  /system/lib/libc.so
11-02 16:39:39.903: I/DEBUG(3257):     beb665c0  02079f98  [heap]
11-02 16:39:39.913: I/DEBUG(3257):     beb665c4  40135525  /system/lib/libutils.so
11-02 16:39:39.913: I/DEBUG(3257):     beb665c8  02079f98  [heap]
11-02 16:39:39.913: I/DEBUG(3257):     beb665cc  00000000  
11-02 16:39:39.913: I/DEBUG(3257):     beb665d0  02079f84  [heap]
11-02 16:39:39.913: I/DEBUG(3257):     beb665d4  40135525  /system/lib/libutils.so
11-02 16:39:39.913: I/DEBUG(3257):     beb665d8  02079f84  [heap]
11-02 16:39:39.913: I/DEBUG(3257):     beb665dc  00000000  
11-02 16:39:39.913: I/DEBUG(3257):     beb665e0  beb66624  [stack]
11-02 16:39:39.913: I/DEBUG(3257):     beb665e4  02079f98  [heap]
11-02 16:39:39.913: I/DEBUG(3257):     beb665e8  00000001  
11-02 16:39:39.913: I/DEBUG(3257):     beb665ec  401355ff  /system/lib/libutils.so
11-02 16:39:39.913: I/DEBUG(3257):     beb665f0  02079da8  [heap]
11-02 16:39:39.913: I/DEBUG(3257):     beb665f4  0208ecb8  [heap]
11-02 16:39:39.913: I/DEBUG(3257):     beb665f8  0202ed20  [heap]
11-02 16:39:39.913: I/DEBUG(3257):     beb665fc  02079da8  [heap]
11-02 16:39:39.913: I/DEBUG(3257):     beb66600  0202ed20  [heap]
11-02 16:39:39.913: I/DEBUG(3257):     beb66604  0202ed20  [heap]
11-02 16:39:39.913: I/DEBUG(3257):     beb66608  02079f98  [heap]
11-02 16:39:39.913: I/DEBUG(3257):     beb6660c  409c17e5  /system/lib/libhwui.so
11-02 16:39:39.913: I/DEBUG(3257):     beb66610  beb666d0  [stack]
11-02 16:39:39.913: I/DEBUG(3257):     beb66614  0208ecb8  [heap]
11-02 16:39:39.913: I/DEBUG(3257):     beb66618  0202ed20  [heap]
11-02 16:39:39.913: I/DEBUG(3257):     beb6661c  0208ecb8  [heap]
11-02 16:39:39.913: I/DEBUG(3257):     beb66620  43f00000  /dev/ashmem/dalvik-heap (deleted)
11-02 16:39:39.913: I/DEBUG(3257):     beb66624  0202ed20  [heap]
11-02 16:39:39.913: I/DEBUG(3257):     beb66628  020e1f58  [heap]
11-02 16:39:39.913: I/DEBUG(3257):     beb6662c  40103588  
11-02 16:39:39.923: I/DEBUG(3257):     beb66630  0218eff0  [heap]
11-02 16:39:39.923: I/DEBUG(3257):     beb66634  0218f0d8  [heap]
11-02 16:39:39.923: I/DEBUG(3257):     beb66638  40103588  
11-02 16:39:39.923: I/DEBUG(3257):     beb6663c  40103588  
11-02 16:39:39.923: I/DEBUG(3257):     beb66640  020e1f60  [heap]
11-02 16:39:39.923: I/DEBUG(3257):     beb66644  020e2048  [heap]
11-02 16:39:39.923: I/DEBUG(3257):     beb66648  beb666d0  [stack]
11-02 16:39:39.923: I/DEBUG(3257):     beb6664c  40103498  
11-02 16:39:39.923: I/DEBUG(3257):     beb66650  00000008  
11-02 16:39:39.923: I/DEBUG(3257):     beb66654  400cfa4d  /system/lib/libc.so
11-02 16:39:39.923: I/DEBUG(3257):     beb66658  020e1f60  [heap]
11-02 16:39:39.923: I/DEBUG(3257):     beb6665c  020b9348  [heap]
11-02 16:39:39.923: I/DEBUG(3257):     beb66660  021821c0  [heap]
11-02 16:39:39.923: I/DEBUG(3257):     beb66664  16335a17  
11-02 16:39:39.923: I/DEBUG(3257):     beb66668  021821b8  [heap]
11-02 16:39:39.923: I/DEBUG(3257):     beb6666c  021822a0  [heap]
11-02 16:39:39.923: I/DEBUG(3257):     beb66670  000000e8  
11-02 16:39:39.923: I/DEBUG(3257):     beb66674  400d089d  /system/lib/libc.so
11-02 16:39:42.593: I/DEBUG(3257): debuggerd committing suicide to free the zombie!
11-02 16:39:42.603: I/ActivityManager(149): Process com.polaroid.kidsmusic (pid 3556) has died.
11-02 16:39:42.603: W/ActivityManager(149): Force removing ActivityRecord{40f93768 com.polaroid.kidsmusic/.MainActivity}: app died, no saved state
11-02 16:39:42.613: W/AudioFlinger(86): session id 829 not found for pid 86
11-02 16:39:42.613: I/DEBUG(3882): debuggerd: Sep 29 2012 11:09:03
11-02 16:39:42.623: I/WindowManager(149): WIN DEATH: Window{4118d898 com.polaroid.kidsmusic/com.polaroid.kidsmusic.MainActivity paused=false}
11-02 16:39:42.623: W/WindowManager(149): Force-removing child win Window{41574080 SurfaceView paused=false} from container Window{4118d898 com.polaroid.kidsmusic/com.polaroid.kidsmusic.MainActivity paused=false}
11-02 16:39:42.643: W/WindowManager(149): Failed looking up window
11-02 16:39:42.643: W/WindowManager(149): java.lang.IllegalArgumentException: Requested window android.os.BinderProxy@41159418 does not exist
11-02 16:39:42.643: W/WindowManager(149):   at com.android.server.wm.WindowManagerService.windowForClientLocked(WindowManagerService.java:7168)
11-02 16:39:42.643: W/WindowManager(149):   at com.android.server.wm.WindowManagerService.windowForClientLocked(WindowManagerService.java:7159)
11-02 16:39:42.643: W/WindowManager(149):   at com.android.server.wm.WindowState$DeathRecipient.binderDied(WindowState.java:1545)
11-02 16:39:42.643: W/WindowManager(149):   at android.os.BinderProxy.sendDeathNotice(Binder.java:417)
11-02 16:39:42.643: W/WindowManager(149):   at dalvik.system.NativeStart.run(Native Method)
11-02 16:39:42.643: I/WindowManager(149): MediaPlayer.is not PlayingVideo
11-02 16:39:42.643: I/WindowManager(149): WIN DEATH: null
11-02 16:39:42.713: V/TabletStatusBar(209): setLightsOn(true)
11-02 16:39:42.723: W/InputManagerService(149): Got RemoteException sending setActive(false) notification to pid 3556 uid 10032

- Junaid

尝试阅读https://groups.google.com/forum/?fromgroups=#!topic/android-ndk/YeoQxKvf08M，使用该信息可以获得本地堆栈并了解问题所在。然后，使用本地堆栈信息更新您的问题。 - Yury

我没有使用任何本地代码，那么为什么我需要 NDK 呢？你能解释一下吗？:-/ - Junaid

好的，我会尽快获取本地堆栈信息并更新我的问题。谢谢。 - Junaid

我猜上下文出了问题。我认为你在某个地方使用了你的Activity的上下文而不是你的服务，但我不确定。 - Yury

@CodeShane：没有，我还没有使用包含本地代码的库。 - Junaid

显示剩余4条评论

4个回答

9

我找到了问题所在。

我一直在一个媒体播放器的onPrepareListener()里初始化一个叫Visualizer的类对象。因此，每当媒体播放器调用prepare()函数时，Visualizer对象都会被重复创建，这样就会影响内存并导致应用程序崩溃。

将Visualizer初始化代码从onPrepareListener()中移除，并仅初始化一次对象即可解决该问题。现在，应用程序不再崩溃。

- Junaid

嗨@Junaid，我在使用谷歌LG Nexus 4设备时遇到了同样的崩溃问题，我调用了一个在线找到的自定义LocationManaer，它使用GPSTracker类进行初始化以便于LocationChangeListener。我在我的3-4个应用程序中使用了相同的类，从未发生过崩溃，但现在我遇到了这个错误，注释掉初始化locationmanagerlistener后就不会崩溃...你有任何解决方法吗？ - Abdul Wahab

6

错误很可能来自尝试删除或使用未初始化的指针。由于您没有直接操作指针，而是使用其他库，所以有可能您没有按照库的要求初始化库。或者，库实现者忽略了初始化他们的指针，并且还没有意识到这一点，因为错误可能不总是显现出来 - 正如您所发现的那样。因为指针指向内存中的地址，如果指针没有初始化，它很可能包含垃圾值（不是有效的内存地址）。错误来自于尝试访问/删除不存在或您无权访问的内存地址。使它看起来随机的原因通常是因为内存已经预初始化为0，这也是大多数系统上NULL的值。运行您的系统/应用程序足够长时间会使内存变得更脏。此外，我发现声明未初始化变量时遇到0的几率因不同系统而异，因此某些系统可能会比其他系统更容易崩溃。个人例子：当我实例化一个类时，该类具有指针作为私有成员，但我在类初始化期间忘记初始化指针时就遇到了这个错误。稍后当该类被销毁时，它会尝试删除指针，但是因为指针没有初始化为NULL，它可能具有一些垃圾值，因此有时会导致崩溃，而有时则不会。以下是我最近遇到的问题的简化示例：

class BadFoo
{
public:
    BadFoo() {} // BAD! We didn't initialize the pointer
    ~BadFoo() {
        if (myPtr) {
            delete myPtr; // CRASH HERE IF INVALID ADDRESS
        }
    }
    // OTHER MEMBER FUNCTIONS HERE

private:
    int* myPtr;
}




class GoodFoo
{
public:
    GoodFoo() : myPtr(NULL) {} // GOOD! Can't be garbage value now
    ~GoodFoo() {
        if (myPtr) {
            delete myPtr;
        }
    }
    // OTHER MEMBER FUNCTIONS HERE

private:
    int* myPtr;
}

- PolyMesh

我遇到了类似的崩溃问题，请帮忙解决。我已经得到了tombstone文件，因为我可以在模拟器中重新创建它。https://dev59.com/Rqfja4cB1Zd3GeqPxo9q - pradex

1

在我的情况下，问题是将一个不好的 Typeface 设置到了一个 TextView 上。在进程死亡后，一个好的字体变得不好。当用户回到我的应用时，我没有重新初始化这个字体，而是继续使用同样不好的字体。因此，这触发了致命错误。

2020-03-06 10:35:58.122 com.xxxxxx.xxxxxx A/libc: Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x2000 in tid 24474 (com.xxxxxx.xxxxxx), pid 24474 (com.xxxxxx.xxxxxx)
2020-03-06 10:35:58.141 ? E/DEBUG: failed to readlink /proc/24474/fd/47: No such file or directory
2020-03-06 10:35:58.141 ? E/DEBUG: failed to readlink /proc/24474/fd/48: No such file or directory
2020-03-06 10:35:58.176 ? A/DEBUG: *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
2020-03-06 10:35:58.176 ? A/DEBUG: Build fingerprint: 'google/sdk_gphone_x86/generic_x86:10/QSR1.190920.001/5891938:user/release-keys'
2020-03-06 10:35:58.176 ? A/DEBUG: Revision: '0'
2020-03-06 10:35:58.176 ? A/DEBUG: ABI: 'x86'
2020-03-06 10:35:58.176 ? A/DEBUG: Timestamp: 2020-03-06 10:35:58+0530
2020-03-06 10:35:58.176 ? A/DEBUG: pid: 24474, tid: 24474, name: com.xxxxxx.xxxxxx  >>> com.xxxxxx.xxxxxx <<<
2020-03-06 10:35:58.176 ? A/DEBUG: uid: 10140
2020-03-06 10:35:58.176 ? A/DEBUG: signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x2000

完整的堆栈跟踪

- rupinderjeet

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- CodeShane · Accepted Answer

18

看起来有几种可能性（不出所料），在SO上有很多相关问题。

可能是内存不足

这肯定是使用本机代码的风险之一！

两个不同线程同时调用同一个函数

无效堆地址和致命信号 11

内存损坏

glShaderBinary 使用中致命信号 11 和 INVALID HEAP ADDRESS IN dlfree 错误

所以...祝你好运！ :/

- CodeShane

嗨@CodeShane，我在使用谷歌LG Nexus 4设备时遇到了同样的崩溃问题，调用自定义LocationManaer，它使用我在网上找到的GPSTracker类进行初始化，以便将其用于LocationChangeListener。我在我的3-4个应用程序中使用相同的类，从未发生过崩溃，但现在我有这个错误，注释掉初始化locationmanagerlistener不会崩溃... 你有什么想法如何解决这个问题。 - Abdul Wahab

1

虽然你的崩溃可能类似（本地崩溃？），但它显然具有不同的用例、不同的库，并且距离这个无关问题发布已经两年了。我强烈建议你发布自己的问题，详细描述问题（最好附带代码示例和错误日志），并描述你尝试解决问题所采取的步骤（将此问题链接作为你的研究的一部分）。这是StackOverflow的政策，但更重要的是，它将吸引更多开发者关注你的问题，并极大地提高你获得有用答案的机会。谢谢。 - CodeShane

@CodeShane 我遇到了类似的崩溃问题，请在能力范围内帮助我。我已经得到了墓碑文件，因为我可以在模拟器中重新创建它。https://dev59.com/Rqfja4cB1Zd3GeqPxo9q - pradex