【问题标题】:How to examine a core file generated when program is running under valgrind如何检查程序在 valgrind 下运行时生成的核心文件
【发布时间】:2017-05-01 16:09:50
【问题描述】:

我有一个程序 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 documentation,我猜我需要add-symbol-file filename address 之类的东西,但我不确定如何确定地址。

【问题讨论】:

    标签: c gdb valgrind symbols core


    【解决方案1】:

    我试图弄清楚如何从 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
    

    【讨论】:

    • 是的,你完全正确。我在 Ubuntu 下使用类似的简单测试可执行文件得到了与您相同的结果。不幸的是,我拥有的系统是一个专有的嵌入式(基于 Linux)的系统,它带有有趣的 GDB 包装器和一些额外的花里胡哨的 codumper 设施。我将不得不深入研究...
    • 请注意,您还可以使用 gdb+vgdb 调试在 Valgrind 下运行的应用程序(请参阅 valgrind.org/docs/manual/…)。附注:您在命令行上指定了 2 个工具,只有一个会真正被激活。
    • 我认为这个答案没有帮助,并且提供的示例之所以有效,是因为它没有使用与 OP 相同的选项。
    猜你喜欢
    • 1970-01-01
    • 2012-10-24
    • 2023-04-06
    • 2011-07-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2021-06-02
    相关资源
    最近更新 更多