Android NDK memcpy 崩溃，在 libc.so 中带有 proguard 的断回跟踪

Question

在使用 Android 2.3.4 附带的 Amazon Kindle Fire 解决问题时遇到了一些困难，崩溃是 SIGSERV 并且并不总是重现。

App本身是原生游戏，有几个点会闪退。很难通过日志语句确定究竟是什么导致了崩溃。我已经能够在保存游戏中捕获游戏状态，以继续恢复并运行一个有问题的部分。

此问题只会在启用 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 进入 Debug模式并启用了调试符号并运行了 gdb。当崩溃发生时，通过 gdb 回溯被丢弃，因为帧上的返回指针已被覆盖。

使用 addr2line，内存引用显示它在 memcpy 中崩溃了。对 gdb 的一些挖掘表明它是 memcpy 的第一个参数被传递了一个 NULL 指针。

尝试了很多方法试图找到这个问题的根源，甚至尝试用我自己定制的函数替换 memcpy 函数来捕获问题。然而，在 ARM 指针数学下的重定向遇到了一些问题。

堆栈上的返回指针，而不是 lr 寄存器似乎指向 JITed 代码。这不是我调用 memcpy 的 native 代码。

在手动检查堆栈时，似乎没有任何内容指向我的任何 native 代码。

关于获取更多有用信息以查明问题或什至使用 memcpy 执行替换功能的任何建议？或者从 native 崩溃中获取有用的 dalvik 堆栈跟踪。

Answer 1

我遇到了同样的问题。在 Android 3.x 上工作得很好，然后你显示的同样的事情发生在 Android 4 上。只需使用 memmove，只要你想使用 memcpy。