gdb：地址范围映射
我正在分析这个核心转储，
Program received signal SIGABRT, Aborted.
0xb7fff424 in __kernel_vsyscall ()
(gdb) where
#0 0xb7fff424 in __kernel_vsyscall ()
#1 0x0050cd71 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#2 0x0050e64a in abort () at abort.c:92
#3 0x08083b3b in ?? ()
#4 0x08095461 in ?? ()
#5 0x0808bdea in ?? ()
#6 0x0808c4e2 in ?? ()
#7 0x080b683b in ?? ()
#8 0x0805d845 in ?? ()
#9 0x08083eb6 in ?? ()
#10 0x08061402 in ?? ()
#11 0x004f8cc6 in __libc_start_main (main=0x805f390, argc=15, ubp_av=0xbfffef64, init=0x825e220, fini=0x825e210,
rtld_fini=0x4cb220 <_dl_fini>, stack_end=0xbfffef5c) at libc-start.c:226
#12 0x0804e5d1 in ?? ()
我无法知道哪个函数 ?? 映射到 OR 例如 ?? 中的 #10 0x08061402 () 属于哪个地址范围...
请帮我调试这个。
I am analyzing this core dump
Program received signal SIGABRT, Aborted.
0xb7fff424 in __kernel_vsyscall ()
(gdb) where
#0 0xb7fff424 in __kernel_vsyscall ()
#1 0x0050cd71 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#2 0x0050e64a in abort () at abort.c:92
#3 0x08083b3b in ?? ()
#4 0x08095461 in ?? ()
#5 0x0808bdea in ?? ()
#6 0x0808c4e2 in ?? ()
#7 0x080b683b in ?? ()
#8 0x0805d845 in ?? ()
#9 0x08083eb6 in ?? ()
#10 0x08061402 in ?? ()
#11 0x004f8cc6 in __libc_start_main (main=0x805f390, argc=15, ubp_av=0xbfffef64, init=0x825e220, fini=0x825e210,
rtld_fini=0x4cb220 <_dl_fini>, stack_end=0xbfffef5c) at libc-start.c:226
#12 0x0804e5d1 in ?? ()
I'm not able to know which function ?? maps to OR for instance #10 0x08061402 in ?? ()
falls in which address range ...
Please help me debug this.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
您的程序没有调试符号。使用
-g重新编译它。确保您没有剥离可执行文件，例如将-s传递给链接器。Your program has no debugging symbols. Recompile it with
-g. Make sure you haven't stripped your executable, e.g. by passing-sto the linker.尽管 @user794080 没有这么说，但他的程序很可能是 32 位 Linux 可执行文件。
有两个可能的原因（我能想到）主可执行文件中的符号（以及堆栈跟踪中 [0x08040000,0x08100000）范围内的所有符号都来自主可执行文件）不显示。
ninjalj 的回答），并且经常发生在“-s”传递到链接器时，也许是无意的。
Even though @user794080 didn't say so, it appears exceedingly likely that his program is a 32-bit linux executable.
There are two possible reasons (I can think of) for symbols from main executable (and all symbols in the stack trace in the range [0x08040000,0x08100000) are from the main executable) not to show up.
ninjalj's answer), and often happens when '-s' is passed into the linker, perhaps inadvertently.
要了解哪些库映射到应用程序中，请记录程序的 pid，在 gdb 中停止并在其他控制台中运行，
其中 $pid 是已停止进程的 pid。映射文件的格式在 http://linux.die.net/man/5/proc 中描述 - 从"/proc/[number]/maps 开始
包含当前映射的内存区域及其访问权限的文件。”
此外，如果您的操作系统不使用 ASLR（地址空间布局随机化）或者它在您的程序中被禁用，您可以用来
列出链接库但是如果打开了 ASLR，您将无法获得真正的内存映射范围信息，因为它会随着程序的每次运行而改变，但即使这样您也会知道动态链接并安装了哪些库。他们的调试信息。
To know what libraries are mapped into the application, record a pid of you program, stopped in gdb and run in other console
wher $pid is the pid of stopped process. Format of the maps file is described at http://linux.die.net/man/5/proc - starting from "/proc/[number]/maps
A file containing the currently mapped memory regions and their access permissions."
Also, if your OS don't use a ASLR (address space layout randomization) or it is disabled for your program, you can use
to list linked libraries and their memory ranges. But if ASLR is turned on, you will be not able to get real memory mapping ranges info, as it will change for each run of program. But even then you will know, what libraries are linked in dynamically and install a debuginfo for them.
堆栈可能已损坏。这 ”？？”如果堆栈上的返回地址已被覆盖（例如缓冲区溢出），则可能会发生这种情况。
The stack might be corrupted. The "??" can happen if the return address on the stack has been overwritten by, for example, a buffer overflow.