如何检查程序在valgrind下运行时生成的core文件

问题描述 投票:0回答:1

我有一个程序

myprog
,我一直在 valgrind 下运行:

/usr/bin/valgrind --tool=massif --tool=memcheck --leak-check=yes --track-origins=yes --log-file=/tmp/valgrind%p /opt/bin/myprog

我不太确定 valgrind 在幕后如何工作的细节,但是当以这种方式运行时,我看到

valgrind
有 pid,但
myprog
没有。因此,我假设 valgrind 在同一进程空间中运行
myprog
并使用一些魔法来加载目标程序。

myprog
似乎已击中
assert()
并且已生成核心文件。我想使用 GDB 检查这个核心文件,这样我就可以深入了解
assert()
的原因。我正在尝试弄清楚如何从 myprog 加载使用 GDB 所需的符号。

如果我使用

file valgrind
,那么这只会加载 valgrind 符号,而不会加载
myprog

中的任何内容

如果我使用

file myprog
,那么核心文件(由valgrind生成)将与可执行文件(myprog)不匹配。

我有什么方法可以告诉GDB,即使这里的“主机”进程是

valgrind
,我们也想加载
myprog
符号,因为这是我们真正感兴趣的程序?

查看GDB文档,我猜我需要类似

add-symbol-file filename address
的东西,但我不确定如何找出地址是什么。

c gdb valgrind symbols core-file
1个回答
3
投票

我正在尝试找出如何从 myprog 加载使用 GDB 所需的符号。

通常的方式:

gdb ./myprog vgcore.1234

如果我使用

file myprog
,那么核心文件(由valgrind生成)将与可执行文件(myprog)不匹配。

应该匹配。要么你做错了什么(一定要告诉准确你在做什么),或者你在

valgrind
gdb
中存在错误。

示例:

$ cat foo.c
int foo() { abort(); }
int bar() { return foo(); }
int main() { return bar(); }

$ gcc -g -w foo.c
$ valgrind ./a.out

==84263== Using Valgrind-3.9.0.SVN and LibVEX; rerun with -h for copyright info
==84263== Command: ./a.out
==84263==
==84263==
==84263== HEAP SUMMARY:
==84263==     in use at exit: 0 bytes in 0 blocks
==84263==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
...

$ ls -lrt
total 2116
-rw-r----- 1 er eng      80 Dec 15 20:18 foo.c
-rwxr-x--- 1 er eng    9558 Dec 15 20:21 a.out
-rw------- 1 er eng 4243434 Dec 15 20:21 vgcore.84263

$ gdb -q ./a.out vgcore.84263    
Reading symbols from ./a.out...done.
[New LWP 84263]
Core was generated by `'.
Program terminated with signal SIGABRT, Aborted.
#0  0x0000000004a5bc37 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56  ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  0x0000000004a5bc37 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x0000000004a5f028 in __GI_abort () at abort.c:89
#2  0x0000000000400536 in foo () at foo.c:1
#3  0x0000000000400544 in bar () at foo.c:2
#4  0x0000000000400554 in main () at foo.c:3
© www.soinside.com 2019 - 2024. All rights reserved.