Dig*_*uma 6 c debugging gdb magic-numbers backtrace
我正在查看我在GDB中调试的程序的以下回溯:
Thread 7 (Thread 3983):
#0 0xf7737430 in __kernel_vsyscall ()
#1 0x41b85412 in __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/i386/i486/lowlevellock.S:142
#2 0x41b80d6d in _L_lock_686 () from libpthread.so.0
#3 0xfbad8001 in ?? ()
#4 0x080eac80 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
特别是我对0xfbad8001的帧地址及其含义感兴趣.
该平台基于x86,因此该未对齐地址无效.鉴于"坏"被编码为十六进制值,我猜这是一个神奇的数字,但到目前为止,我还无法确定是谁设置了这个值或为什么.我试图在谷歌和在线LXR数据库中搜索内核和glibc,但是没有发现任何实际设置此值的代码行.
如果我谷歌搜索"fbad8001",那么有许多点击在回溯和内存转储中显示此地址.所以这个特殊值似乎有一些意义,我假设它是某个地方的神奇数字,但到目前为止我还没能找到设置它的代码.
谁设定了这个值,它意味着什么？
内核基于Linux 3.4.10,glibc为2.15.
除了内核和glibc源代码外,我还通过gcc,gdb和binutils源代码,但仍然没有看到任何吸烟枪.我不知道还能在哪里看.
我对此的解释是,它是一个永远不会被看到的填充值,并由一个或多个(未指定的)系统程序员非正式地选择以适应特定(未指定的)目的.
请注意,上面的地址也是不对齐的.这表明你从那里读下来的所有东西都是可疑的.
我同意fbad8001可能是一个选定的值,但不是一个重要的值.如果您想进一步调查,您需要使用合适的调试工具直接检查堆栈.您应该能够通过检查找到有效的堆栈帧(如果有的话),并且您可能会发现该值的许多实例(或其他类似的非法值)填充不希望达到的堆栈部分.
如果这是一个调试版本,您可能会在堆栈帧之间找到这些值的带作为标记.如果先前的堆栈帧被破坏,则该值可能很长.直到你看,你才会知道.
如果您可以找出对堆栈特定区域负责的内容,您将更好地了解该问题的原因.我的猜测是你会学到很多,并且通过这条道路来实现很少.