使用android ndk进行内存损坏调试

本文介绍了使用android ndk进行内存损坏调试的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

在我的android应用程序的本机部分出现段错误，此刻void函数返回到其调用者.为了更好地可视化，我在被调用方的调用之后紧接着在被调用方函数的末尾放置了一条日志语句，在调用方函数中放置了一条日志语句(对双关语很抱歉). 在logcat中，第一条消息被打印，第二条则没有(应用程序崩溃).

I am getting a segfault in the native part of my android app, in the moment a void function returns to its caller. To visualize better, I put a log statement at the end of the callee function, and one in the caller function, right after the call to the callee (sorry for the pun). In the logcat, the first message is printed, and the second not (the app crashes).

考虑到可能的内存损坏，我决定激活malloc调试(在adb shell中给出"setprop libc.debug.malloc 10").然后，我从被调用者函数的末尾收到日志消息后，立即在logcat中得到此消息:

Thinking about a possible memory corruption I decided to activate malloc debug (giving "setprop libc.debug.malloc 10" in adb shell). Then, i get this in the logcat right after the log message from the end of the callee function:

D/MyApp - NativeSide(12778): I am the callee function and I am about to return! E/libc (12778): *** FREE CHECK: buffer 0x82869900 corrupted 16 bytes before allocation E/libc (12778): call stack: E/libc (12778): 0: 8000e3ea E/libc (12778): 1: 8000e49c E/libc (12778): 2: 8000e4e2 E/libc (12778): 3: 8000e540 E/libc (12778): 4: afd14ccc E/libc (12778): 5: 81258188 E/libc (12778): 6: 81258188 E/libc (12778): 7: 81258188 E/libc (12778): 8: 81258188 E/libc (12778): 9: 81258188 E/libc (12778): 10: 81258188 E/libc (12778): 11: 81258188 E/libc (12778): 12: 81258188 E/libc (12778): 13: 81258188 E/libc (12778): 14: 81258188 E/libc (12778): 15: 81258188 E/libc (12778): 16: 81258188 E/libc (12778): 17: 81258188 E/libc (12778): 18: 81258188 E/libc (12778): 19: 81258188

我找不到有关如何解密此输出的任何信息.每行显示的数字在每次启动应用程序时都会发生变化.我希望有一种方法可以使用此信息作为发生损坏的线索，因为我无法从代码中找到它.我也尝试使用"-fstack-check标志建立本机库，但是我不能说我是否在日志中有更多信息(似乎没有，但我可能会错过它们)，或者是否需要做其他事情得到他们.

I couldn't find any information on how to decipher this output. The numbers shown at each line are changing at every app launch. I hope there's a way to use this information as a clue on where the corruption happens, as I can't find it from the code. I also tried building the native libraries with the "-fstack-check flag, but I couldn't say if I got more informations in the log (it seems not but I might have missed them), or whether I need to do other things to get them.

此外，这是堆栈堆，位于"FREE CHECK:"消息之后.

Also, here's the stack dump, coming after the "FREE CHECK:" message.

I/DEBUG (12311): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** I/DEBUG (12311): Build fingerprint: 'google/soju/crespo:2.3/GRH55/79397:user/release-keys' I/DEBUG (12311): pid: 12778, tid: 12907 >>> com.ntrack.tuner <<< I/DEBUG (12311): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr deadbaad I/DEBUG (12311): r0 deadbaad r1 45ea374c r2 00000027 r3 00000000 I/DEBUG (12311): r4 00000080 r5 45ea374c r6 8003422e r7 45ea37b4 I/DEBUG (12311): r8 45da4000 r9 a811eca5 10 00100000 fp 00000001 I/DEBUG (12311): ip ffffffff sp 45ea3738 lr 8000f623 pc 8000f650 cpsr 20000030 I/DEBUG (12311): d0 3f9664f48406d639 d1 3f8226e3e96e8495 I/DEBUG (12311): d2 3faba1ba1bb34201 d3 0000000000000000 I/DEBUG (12311): d4 3d7943379e56fd24 d5 3d8f940585cd5f95 I/DEBUG (12311): d6 3f2cf2145b888497 d7 3f2cf214636d85f8 I/DEBUG (12311): d8 0000000000000000 d9 0000000000000000 I/DEBUG (12311): d10 0000000000000000 d11 0000000000000000 I/DEBUG (12311): d12 0000000000000000 d13 0000000000000000 I/DEBUG (12311): d14 0000000000000000 d15 0000000000000000 I/DEBUG (12311): scr 20000010 I/DEBUG (12311):

任何事情，关于典型检查内容或使用malloc调试信息的方式的建议都将大有帮助，谢谢！

Anything, a suggestion on the typical things to check or just the way to make use of the malloc debug informations would be of great help, thanks!

推荐答案

对我来说，这是

在我的android应用的本机部分出现段错误，此刻void函数返回其调用者.

a segfault in the native part of my android app, in the moment a void function returns to its caller.

表示堆栈损坏(不仅仅是堆栈损坏).您要从中返回的函数(以及从它调用的每个函数中)返回的状态是什么?

means stack corruption (more than heap corruption). What state is stored on the stack of this function you're returning from (and from every function it calls ..)?

您看到的调用堆栈输出应该是检测到损坏时堆栈上每个函数的地址.您需要知道库加载到的地址，才能将这些地址映射回.so中的符号. (我认为这个问题会有所帮助:如何在Android中使用addr2line )

The call stack output you're seeing should be the address of each function on the stack at the time the corruption was detected. You'll need to know what address your library was loaded at to map those back to a symbol in your .so. (I think this question will help: How to use addr2line in Android)

81258188从堆栈转储的顶部重复的事实也表明您可能炸毁了堆栈的底部(重复多次).如果您不知道代码中是否有任何故意的递归，那么找出库的加载位置并将其映射回您的代码可能会很有用.

The fact that 81258188 repeats off the top of the stack dump also suggest that you might've blown out the bottom of the stack (by recursing too many times). If you're not aware of any intentional recursion in your code, then figuring out where your library was loaded and mapping that back to your code could be useful.