在解决 Android 2.3.4 附带的 Amazon Kindle Fire 问题时遇到一些困难，崩溃是 SIGSERV 并且并不总是重现。
该应用程序本身是一个原生游戏，并会在几个点崩溃。很难通过日志语句确定究竟是什么导致了崩溃。我已经能够在保存游戏中捕获游戏状态，以继续恢复和运行一个麻烦的部分。
该问题只会在启用 Proguard 时重现，我尝试了 Proguard 的各种配置以禁用各种功能。proguard中使用了以下内容，对问题没有影响：
-keepclasseswithmembers class *{
native <methods>;
}
-keepclasseswithmembers class * {
*** *Callback(...);
}
-dontshrink
-dontoptimize
-dontpreverify
-keep class javax.** { *; }
-keep class java.** { *; }
-keep class org.** { *; }
-keep class android.** { *; }
-keep class com.** { *; }
添加 -dontobfuscate 似乎可以解决问题，但是由于效果的随机性，我无法 100% 确认。
堆栈跟踪如下：
I/DEBUG (23231): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
I/DEBUG (23231): Build fingerprint: 'generic/blaze/blaze:2.3.4 GINGERBREAD/6.3.1_user_4107720:user/release-keys'
I/DEBUG (23231): pid: 23238, tid: 23409 >>> mypackage <<<
I/DEBUG (23231): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000000
I/DEBUG (23231): r0 00000000 r1 0045ae68 r2 00000fc0 r3 006f003b
I/DEBUG (23231): r4 003b0059 r5 00040013 r6 fff60000 r7 0004fff5
I/DEBUG (23231): r8 00080009 r9 0046d350 10 00100000 fp 00000001
I/DEBUG (23231): ip 00120008 sp 48c2ee24 lr 00070013 pc afd0cfe0 cpsr 20000110
I/DEBUG (23231): d0 0000001900000110 d1 be94da8200000000
I/DEBUG (23231): d2 bfd180bc00000000 d3 3feec709dc3a0300
I/DEBUG (23231): d4 be86935e00000000 d5 bfd5a7f8c70233a6
I/DEBUG (23231): d6 458000009eb93fdb d7 00000b9a00000b9a
I/DEBUG (23231): d8 00000000103a3c9d d9 0000000000000000
I/DEBUG (23231): d10 0000000000000000 d11 0000000000000000
I/DEBUG (23231): d12 0000000000000000 d13 0000000000000000
I/DEBUG (23231): d14 0000000000000000 d15 0000000000000000
I/DEBUG (23231): d16 3fe7356a68b6af7e d17 3ff0000000000000
I/DEBUG (23231): d18 be607fc1c458778e d19 bfa7cc5f02a59422
I/DEBUG (23231): d20 4000000000000000 d21 3f114aff86ff44bc
I/DEBUG (23231): d22 bebbaaeb53350f0d d23 bfd48eb6ede7d000
I/DEBUG (23231): d24 3e66376972bea4d0 d25 3fd193d7807f5e77
I/DEBUG (23231): d26 3ff4000000000000 d27 bfa7cc5f02a59424
I/DEBUG (23231): d28 c002b4ff18e04675 d29 bfd48eb70ee75389
I/DEBUG (23231): d30 3c6ad5a68fb54afb d31 be607fc1c4800000
I/DEBUG (23231): scr 80000012
I/DEBUG (23231):
I/DEBUG (23231): #00 pc 0000cfe0 /system/lib/libc.so
I/DEBUG (23231): #01 lr 00070013 <unknown>
I/DEBUG (23231):
I/DEBUG (23231): code around pc:
I/DEBUG (23231): afd0cfc0 24c04001 24c05001 e2522020 ba000005
I/DEBUG (23231): afd0cfd0 f5d1f060 f5d1f080 e8b151f8 e2522020
I/DEBUG (23231): afd0cfe0 e8a051f8 aafffffa e2922020 0a00000c
I/DEBUG (23231): afd0cff0 e1b0ce02 28b10078 48b10180 28a00078
I/DEBUG (23231): afd0d000 48a00180 e1b0cf02 24913004 40d140b2
I/DEBUG (23231):
I/DEBUG (23231): code around lr:
I/DEBUG (23231): 0006fff0 00000000 00000000 00000000 00000000
I/DEBUG (23231): 00070000 00000000 00000000 00000000 00000000
I/DEBUG (23231): 00070010 00000000 00000000 00000000 00000000
I/DEBUG (23231): 00070020 00000000 00000000 00000000 00000000
I/DEBUG (23231): 00070030 00000000 00000000 00000000 00000000
I/DEBUG (23231):
I/DEBUG (23231): stack:
I/DEBUG (23231): 48c2ede4 00000000
I/DEBUG (23231): 48c2ede8 00000000
I/DEBUG (23231): 48c2edec 00000000
I/DEBUG (23231): 48c2edf0 00000000
I/DEBUG (23231): 48c2edf4 00000000
I/DEBUG (23231): 48c2edf8 00000000
I/DEBUG (23231): 48c2edfc 00000000
I/DEBUG (23231): 48c2ee00 00000000
I/DEBUG (23231): 48c2ee04 00000000
I/DEBUG (23231): 48c2ee08 00000000
I/DEBUG (23231): 48c2ee0c 00000000
I/DEBUG (23231): 48c2ee10 002275c4
I/DEBUG (23231): 48c2ee14 00000001
I/DEBUG (23231): 48c2ee18 df002777
I/DEBUG (23231): 48c2ee1c e3a070ad
I/DEBUG (23231): 48c2ee20 48c2ee5c
I/DEBUG (23231): #00 48c2ee24 002275a0
I/DEBUG (23231): 48c2ee28 00001000
I/DEBUG (23231): 48c2ee2c 48c2ee5c
I/DEBUG (23231): 48c2ee30 00001000
I/DEBUG (23231): 48c2ee34 a811cda9 /system/lib/libutils.so
I/DEBUG (23231): 48c2ee38 00000000
I/DEBUG (23231): 48c2ee3c 81004f45 /system/lib/libOpenSLES.so
I/DEBUG (23231): 48c2ee40 00000000
I/DEBUG (23231): 48c2ee44 002275a0
I/DEBUG (23231): 48c2ee48 00227eb8
I/DEBUG (23231): 48c2ee4c 00000800
I/DEBUG (23231): 48c2ee50 48c2ee5c
I/DEBUG (23231): 48c2ee54 a903181b /system/lib/libmedia.so
I/DEBUG (23231): 48c2ee58 00000000
I/DEBUG (23231): 48c2ee5c 00000000
I/DEBUG (23231): 48c2ee60 00000001
I/DEBUG (23231): 48c2ee64 00000001
I/DEBUG (23231): 48c2ee68 00000800
为了获取调试信息，我将 proguard 启用到调试模式并启用调试符号并运行 gdb。当崩溃发生时，通过 gdb，回溯被丢弃，因为帧上的返回指针已被覆盖。
使用 addr2line，内存引用显示它在 memcpy 中崩溃了。使用 gdb 进行一些挖掘表明它是 memcpy 的第一个参数被传递了一个 NULL 指针。
已经尝试了很多方法来试图找到这个问题的根源，甚至尝试用我自己定制的函数替换 memcpy 函数来解决这个问题。但是，在 ARM 指针数学下的重定向遇到了一些问题。
堆栈上的返回指针，而不是 lr 寄存器似乎指向 JITed 代码。这不是我的本机代码调用 memcpy。
在手动检查堆栈时，似乎没有任何东西指向我的任何本机代码。
有关获取更多有用信息以查明问题甚至使用 memcpy 执行替换功能的任何建议？或者从本机崩溃中获取有用的 dalvik 堆栈跟踪。