无法在地址函数参数传递问题处访问内存

Question

在我的 main() 函数中，我有一个局部变量：

datastruct pdw_frame;

我用数据填充它并将其传递给main() 中相邻行上的两个函数，例如

datastruct_to_pdw(&pdw_frame, 0, &pdw); /* ok */
hash_streams = get_streams(&pdw_frame, &result_frame); /* not ok */

在使用gdb 进入datastruct_to_pdw() 时，我可以查看第一个函数参数没问题，例如

(gdb) p *pdw_frame

返回结构的描述

然而，当进入第二个函数并尝试做同样的事情时，我得到：

Cannot access memory at address 0xcccccccd

我不明白为什么我可以从第一个函数参数而不是第二个函数参数中取消引用指针

相关函数包含在我从 main() 调用的共享库中。这些函数在不同的文件中定义，它们的原型在不同的头文件中。我检查了我的Makefile 以确保它们都在构建。检查共享库确认两个函数都存在，例如

nm mylib.so

000251a1 T datastruct_to_pdw
00027348 T get_streams

一个函数调用如何工作而不是另一个？

函数原型是：

void datastruct_to_pdw(const datastruct *const pulse_data, size_t i, Pdw *pdw);
stream_t* get_streams(datastruct *pdw_frame, resultstruct *result_frame);

我的共享库的调试版本设置了以下编译器标志：

DEBUG_CFLAGS := -fPIC -g -Wall -DDEBUG=1

使用这些设置，我在从 Makefile 构建时不会收到任何警告

单步执行代码，检查 pdw_frame 的值：

在调用 datastruct_to_pdw() 之前的 main() 中：

(gdb) p pdw_frame
$2 = {ptoa = 0x8051e98, prf = 0x804e008, ppw = 0x804ff50, pamp = 0x8053de0, pbr = 0x8055d28, n = 1000, truth = 0x8057c70}

(gdb) p &pdw_frame
$5 = (datastruct *) 0xbfffe9e0

进入datastruct_to_pdw()：

(gdb) p pulse_data
$4 = (const datastruct * const) 0xbfffe9e0

(gdb) p *pulse_data
$3 = {ptoa = 0x8051e98, prf = 0x804e008, ppw = 0x804ff50, pamp = 0x8053de0, pbr = 0x8055d28, n = 1000, truth = 0x8057c70}

在 main() 中从 datastruct_to_pdw() 返回：

(gdb) p pdw_frame
$9 = {ptoa = 0x8051e98, prf = 0x804e008, ppw = 0x804ff50, pamp = 0x8053de0, pbr = 0x8055d28, n = 1000, truth = 0x8057c70}

(gdb) p &pdw_frame
$8 = (datastruct *) 0xbfffe9e0

进入 get_streams()：

(gdb) p pdw_frame
$10 = (datastruct *) 0x40c24f80 (why is this different to &pdw_frame in main()?)

(gdb) p *pdw_frame
Cannot access memory at address 0x40c24f80 (why??)

在 main() 中从 get_streams() 返回：

(gdb) p pdw_frame
$13 = {ptoa = 0x8051e98, prf = 0x804e008, ppw = 0x804ff50, pamp = 0x8053de0, pbr = 0x8055d28, n = 1000, truth = 0x8057c70}

(gdb) p &pdw_frame
$14 = (datastruct *) 0xbfffe9e0

请注意，我认为我可能对 main() 中的局部变量 pdw_frame（datastruct 类型）和get_streams() 函数（@ 类型）中的参数名称使用相同的名称这一事实987654342@) 可能会导致问题，所以我尝试将get_streams() 的第一个参数重命名为完全不同的名称，但这对错误没有影响

通过 valgrind 运行程序似乎没有任何问题（我认为），例如：

valgrind --tool=memcheck --leak-check=full --show-reachable=yes <my_program>

==12371== 
==12371== HEAP SUMMARY:
==12371==     in use at exit: 1,880 bytes in 1 blocks
==12371==   total heap usage: 35,810 allocs, 35,809 frees, 102,124,128 bytes allocated
==12371== 
==12371== 1,880 bytes in 1 blocks are still reachable in loss record 1 of 1
==12371==    at 0x402A2FB: calloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==12371==    by 0x41D048B: monstartup (gmon.c:134)
==12371==    by 0x8049F60: __gmon_start__ (in /home/ben/projects/glamdring/RESTRICTED/core_harness/build/linux/release/GlamdringHarness_rel)
==12371==    by 0x40D45A9: ??? (in /lib/i386-linux-gnu/librt-2.17.so)
==12371== 
==12371== LEAK SUMMARY:
==12371==    definitely lost: 0 bytes in 0 blocks
==12371==    indirectly lost: 0 bytes in 0 blocks
==12371==      possibly lost: 0 bytes in 0 blocks
==12371==    still reachable: 1,880 bytes in 1 blocks
==12371==         suppressed: 0 bytes in 0 blocks
==12371== 
==12371== For counts of detected and suppressed errors, rerun with: -v
==12371== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Profiling timer expired

我还应该补充一点，当我运行我的单元测试套件时，它编译并链接到单个可执行文件，而不是通过共享库访问函数，我没有任何此类问题。

刚刚添加了一个新功能：

void dummy_utility(int n)
{
    printf("Hello World!");
    return;
}

像这样从main() 调用它：

dummy_utility(42);    

使用gdb 进入它并得到：

(gdb) p n
$4 = 1086476160

它必须选择一个旧的库，但是当我搜索共享库时，例如

$ locate libProgram_dbg.so（_dbg版本有调试符号，没有优化）

我在build/linux/debug 目录中得到一个文件，正如我所期望的那样，当我查看共享库的时间戳时，它显示它刚刚被重建！我真的很困惑..

这是在 gdb 中运行信息寄存器的输出：

就在致电dummy_utility()之前：

(gdb) info registers
eax            0xc  12
ecx            0x0  0
edx            0xbfffe454   -1073748908
ebx            0x11 17
esp            0xbfffe8c0   0xbfffe8c0
ebp            0xbfffec78   0xbfffec78
esi            0x8053dd0    134561232
edi            0x1f38   7992
eip            0x8049d82    0x8049d82 <main+3884>
eflags         0x286    [ PF SF IF ]
cs             0x73 115
ss             0x7b 123
ds             0x7b 123
es             0x7b 123
fs             0x0  0
gs             0x33 51

关于踏入dummy_utility()：

(gdb) info registers
eax            0xbfffea98   -1073747304
ecx            0x0  0
edx            0x2a 42
ebx            0xb7fd9000   -1208119296
esp            0xbfffe8b8   0xbfffe8b8
ebp            0xbfffe8d0   0xbfffe8d0
esi            0x8053dd0    134561232
edi            0x1f38   7992
eip            0xb7fc22cc   0xb7fc22cc <dummy_utility+18>
eflags         0x296    [ PF AF SF IF ]
cs             0x73 115
ss             0x7b 123
ds             0x7b 123
es             0x7b 123
fs             0x0  0
gs             0x33 51

通过dummy_utility() 尝试从main() 返回，gdb 告诉我：

Cannot find bounds of current function

运行ldd ProgramHarness_dbg 给出：

linux-gate.so.1 =>  (0xb76e7000)
libGlamdring_dbg.so => /home/ben/projects/core/build/linux/debug/libProgram_dbg.so (0xb76a4000)
libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xb7646000)
librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0xb763c000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb7489000)
/lib/ld-linux.so.2 (0xb76e8000)
libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xb746e000)

共享库的位置如预期..

Answer 1

对于在 emacs/linux 下运行 gdb 时遇到奇怪行为的任何人

如果您最近升级到 emacs 24，请了解 gdb 已损坏，您现在需要使用 gud-gdb

更多详情请关注：

Emacs gdb not running

gud-gdb emacs 24 not working

Answer 2

我在 mac 上遇到了类似的问题。 我安装了 gdb-apple，然后能够在 python 中加载的共享库中设置断点/检查变量。