Get function names from call stack(从调用堆栈中获取函数名)
本文介绍了从调用堆栈中获取函数名的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！
问题描述
我正在开发一个调用本机代码的 Android 程序.该本机代码存在段错误，并且由于通过 android NDK 进行调试并不是真正可行的，所以我留下了一个如下所示的调用堆栈(从 ddms 捕获).我的问题是，我是否可以在事后手动运行某些东西，将调用堆栈中的内存地址转换为函数名称，这样我就可以看到这是哪里出现了段错误.
I am working on an Android program which calls in to native code. That native code is segfaulting, and since getting debugging working through the android NDK is not really doable, I'm left with a callstack like the following (captured from ddms). My question is whether there is something I can manually run after the fact to translate the memory addresses in the callstack to function names so I can see where this is segfaulting.
谢谢
02-22 14:47:39.231: DEBUG/dalvikvm(504): Trying to load lib /data/data/android.TestApp/lib/libDM.so 0x43b7c938
02-22 14:47:39.301: DEBUG/dalvikvm(504): Added shared lib /data/data/android.TestApp/lib/libDM.so 0x43b7c938
02-22 14:47:39.310: DEBUG/dalvikvm(504): No JNI_OnLoad found in /data/data/android.TestApp/lib/libDM.so 0x43b7c938
02-22 14:47:39.406: DEBUG/dalvikvm(504): +++ not scanning '/system/lib/libwebcore.so' for 'onLoadModel' (wrong CL)
02-22 14:47:39.410: DEBUG/dalvikvm(504): +++ not scanning '/system/lib/libmedia_jni.so' for 'onLoadModel' (wrong CL)
02-22 14:47:39.410: DEBUG/dalvikvm(504): +++ not scanning '/system/lib/libexif.so' for 'onLoadModel' (wrong CL)
02-22 14:47:39.410: DEBUG/dalvikvm(504): +++ not scanning '/system/lib/libsrec_jni.so' for 'onLoadModel' (wrong CL)
02-22 14:47:39.569: INFO/DEBUG(28): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
02-22 14:47:39.569: INFO/DEBUG(28): Build fingerprint: 'generic/sdk/generic/:2.1/ERD79/22607:eng/test-keys'
02-22 14:47:39.569: INFO/DEBUG(28): pid: 504, tid: 504 >>> android.TestApp <<<
02-22 14:47:39.569: INFO/DEBUG(28): signal 11 (SIGSEGV), fault addr 00000008
02-22 14:47:39.581: INFO/DEBUG(28): r0 00000000 r1 00000068 r2 00002350 r3 80facc00
02-22 14:47:39.581: INFO/DEBUG(28): r4 beb3c918 r5 000024b8 r6 fffacafc r7 0000aa98
02-22 14:47:39.581: INFO/DEBUG(28): r8 00000000 r9 000024b8 10 fffacafc fp 00000000
02-22 14:47:39.581: INFO/DEBUG(28): ip afbc30c8 sp beb3c858 lr 80dffdf3 pc 80dfb18a cpsr 40000030
02-22 14:47:39.711: INFO/DEBUG(28): #00 pc 001fb18a /data/data/android.TestApp/lib/libDM.so
02-22 14:47:39.733: INFO/DEBUG(28): #01 pc 001ffdee /data/data/android.TestApp/lib/libDM.so
02-22 14:47:39.740: INFO/DEBUG(28): #02 pc 0031cc2c /data/data/android.TestApp/lib/libDM.so
02-22 14:47:39.754: INFO/DEBUG(28): #03 pc 0031cd74 /data/data/android.TestApp/lib/libDM.so
02-22 14:47:39.761: INFO/DEBUG(28): #04 pc 0000f1f4 /system/lib/libdvm.so
02-22 14:47:39.769: INFO/DEBUG(28): #05 pc 00038018 /system/lib/libdvm.so
02-22 14:47:39.779: INFO/DEBUG(28): #06 pc 000316a2 /system/lib/libdvm.so
02-22 14:47:39.790: INFO/DEBUG(28): #07 pc 0003d31c /system/lib/libdvm.so
02-22 14:47:39.810: INFO/DEBUG(28): #08 pc 00013f58 /system/lib/libdvm.so
02-22 14:47:39.810: INFO/DEBUG(28): #09 pc 00019888 /system/lib/libdvm.so
02-22 14:47:39.820: INFO/DEBUG(28): #10 pc 00018d5c /system/lib/libdvm.so
02-22 14:47:39.846: INFO/DEBUG(28): #11 pc 0004d3bc /system/lib/libdvm.so
02-22 14:47:39.852: INFO/DEBUG(28): #12 pc 00054e74 /system/lib/libdvm.so
02-22 14:47:39.871: INFO/DEBUG(28): #13 pc 00013f58 /system/lib/libdvm.so
02-22 14:47:39.871: INFO/DEBUG(28): #14 pc 00019888 /system/lib/libdvm.so
02-22 14:47:39.889: INFO/DEBUG(28): #15 pc 00018d5c /system/lib/libdvm.so
02-22 14:47:39.889: INFO/DEBUG(28): #16 pc 0004d6d0 /system/lib/libdvm.so
02-22 14:47:39.900: INFO/DEBUG(28): #17 pc 0003a72c /system/lib/libdvm.so
02-22 14:47:39.909: INFO/DEBUG(28): #18 pc 0002be52 /system/lib/libdvm.so
02-22 14:47:39.921: INFO/DEBUG(28): #19 pc 00026cf4 /system/lib/libandroid_runtime.so
02-22 14:47:39.930: INFO/DEBUG(28): #20 pc 000279d8 /system/lib/libandroid_runtime.so
02-22 14:47:39.940: INFO/DEBUG(28): #21 pc 00008cae /system/bin/app_process
02-22 14:47:39.949: INFO/DEBUG(28): #22 pc 0000c2c6 /system/lib/libc.so
02-22 14:47:39.969: INFO/DEBUG(28): #23 pc b00018aa /system/bin/linker
02-22 14:47:39.981: INFO/DEBUG(28): code around pc:
02-22 14:47:39.981: INFO/DEBUG(28): 80dfb178 fffaaac8 4656b570 4644464d 4680b470
02-22 14:47:39.981: INFO/DEBUG(28): 80dfb188 6883b081 1c0d1c08 22b04798 46814442
02-22 14:47:39.981: INFO/DEBUG(28): 80dfb198 46921c10 f73d2600 4642ea90 6c546c13
02-22 14:47:39.981: INFO/DEBUG(28): code around lr:
02-22 14:47:39.981: INFO/DEBUG(28): 80dffde0 1c064a0b 589b447b 681c1c31 f7fb1c20
02-22 14:47:39.981: INFO/DEBUG(28): 80dffdf0 1c05f9c5 d0062800 d0042c00 23001c32
02-22 14:47:39.981: INFO/DEBUG(28): 80dffe00 f7fb1c20 1c28fa15 0000bd70 001a47f8
02-22 14:47:39.981: INFO/DEBUG(28): stack:
02-22 14:47:39.981: INFO/DEBUG(28): beb3c818 afe42ad4
02-22 14:47:39.981: INFO/DEBUG(28): beb3c81c ad07ff50 /system/lib/libdvm.so
02-22 14:47:39.990: INFO/DEBUG(28): beb3c820 0000bd00 [heap]
02-22 14:47:39.990: INFO/DEBUG(28): beb3c824 00000000
02-22 14:47:39.990: INFO/DEBUG(28): beb3c828 00085920 [heap]
02-22 14:47:40.000: INFO/DEBUG(28): beb3c82c 00000000
02-22 14:47:40.000: INFO/DEBUG(28): beb3c830 ffffffff
02-22 14:47:40.000: INFO/DEBUG(28): beb3c834 beb3c850 [stack]
02-22 14:47:40.015: INFO/DEBUG(28): beb3c838 00000000
02-22 14:47:40.015: INFO/DEBUG(28): beb3c83c 00000000
02-22 14:47:40.022: INFO/DEBUG(28): beb3c840 ad563b21 /system/lib/libicuuc.so
02-22 14:47:40.022: INFO/DEBUG(28): beb3c844 00085968 [heap]
02-22 14:47:40.030: INFO/DEBUG(28): beb3c848 00000001
02-22 14:47:40.050: INFO/DEBUG(28): beb3c84c 00000000
02-22 14:47:40.061: INFO/DEBUG(28): beb3c850 df002777
02-22 14:47:40.061: INFO/DEBUG(28): beb3c854 e3a070ad
02-22 14:47:40.070: INFO/DEBUG(28): #00 beb3c858 ad065714 /system/lib/libdvm.so
02-22 14:47:40.070: INFO/DEBUG(28): beb3c85c beb3c918 [stack]
02-22 14:47:40.070: INFO/DEBUG(28): beb3c860 000024b8
02-22 14:47:40.090: INFO/DEBUG(28): beb3c864 fffacafc
02-22 14:47:40.090: INFO/DEBUG(28): beb3c868 00000000
02-22 14:47:40.100: INFO/DEBUG(28): beb3c86c 80faed2c
02-22 14:47:40.100: INFO/DEBUG(28): beb3c870 00000068
02-22 14:47:40.122: INFO/DEBUG(28): beb3c874 80dffdf3 /data/data/android.TestApp/lib/libDM.so
02-22 14:47:40.122: INFO/DEBUG(28): #01 beb3c878 80f510dc /data/data/android.TestApp/lib/libDM.so
02-22 14:47:40.122: INFO/DEBUG(28): beb3c87c 80faed2c
02-22 14:47:40.122: INFO/DEBUG(28): beb3c880 80fa45e0 /data/data/android.TestApp/lib/libDM.so
02-22 14:47:40.122: INFO/DEBUG(28): beb3c884 80f1cc31 /data/data/android.TestApp/lib/libDM.so
02-22 14:47:41.240: DEBUG/Zygote(30): Process 504 terminated by signal (11)
推荐答案
你需要生成一个map文件.map 文件包含可执行文件中的函数地址和内存位置.修改您的构建系统以生成地图文件.
You need to generate a map file. The map file contains the function address and memory locations in your executable. Have your build system modified to generate a map file.
在 map 文件中，您可以使用文本编辑器搜索地址.我曾经编写了一个程序来查找限制给定地址的两个符号.非常适合像您这样的环境.
From the map file, you can use a text editor and search for addresses. I once wrote a program to find the two symbols bounding a given address. Worked great for environments like yours.
这篇关于从调用堆栈中获取函数名的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持编程学习网！
沃梦达教程
本文标题为：从调用堆栈中获取函数名
基础教程推荐
猜你喜欢
- 如何使图像调整大小以在 Qt 中缩放? 2021-01-01
- 在 C++ 中循环遍历所有 Lua 全局变量 2021-01-01
- 为什么语句不能出现在命名空间范围内? 2021-01-01
- Windows Media Foundation 录制音频 2021-01-01
- 从 std::cin 读取密码 2021-01-01
- 如何在不破坏 vtbl 的情况下做相当于 memset(this, ...) 的操作? 2022-01-01
- 为 C/C++ 中的项目的 makefile 生成依赖项 2022-01-01
- 使用从字符串中提取的参数调用函数 2022-01-01
- 如何“在 Finder 中显示"或“在资源管理器中显 2021-01-01
- 管理共享内存应该分配多少内存？(助推) 2022-12-07
