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

时间:2016-12-15 22:50:54

标签: c gdb valgrind symbols core

我有一个程序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,那么corefile(由valgrind生成)将与可执行文件(myprog)不匹配。

有什么方法可以告诉GDB即使这里的“主机”进程是valgrind,我们也想加载myprog符号,因为这是我们实际感兴趣的程序在?

仔细阅读GDB documentation,我猜我需要像add-symbol-file filename address这样的东西,但我不知道如何弄清楚地址是什么。

1 个答案:

答案 0 :(得分:2)

  

我试图找出如何从myprog加载使用GDB所必需的符号。

通常的方式:gdb ./myprog vgcore.1234

  

如果我使用file myprog,则核心文件(由valgrind生成)不会与可执行文件(myprog)匹配。

匹配。你做错了什么(确实告诉完全你正在做什么),或者你在valgrindgdb中有错误。

示例:

$ 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