在解决安卓2.3.4附带的亚马逊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.** { *; }
添加-不要大惊小怪似乎可以消除问题，但由于效果的随机性，我无法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功能来代替memcpy，以当场解决这个问题。然而，在ARM指针数学下重定向时遇到了一些问题。
堆栈上的返回指针，而不是lr寄存器，似乎指向了JITed代码。调用memcpy的不是我的本机代码。
在手动检查堆栈时，似乎没有任何东西指向我的任何本地代码。
关于获取更多有用信息以确定问题，甚至使用memcpy执行替换功能，有什么建议吗？或者从本机崩溃中获得有用的dalvik堆栈跟踪。
我也遇到了同样的问题。在安卓3.x上运行得很好，然后在安卓4上也发生了同样的事情。只要想使用memcpy，就可以使用memmove。