【问题标题】:Analyzing core dump generated by multiple applications with gdb使用 gdb 分析多个应用程序生成的核心转储
【发布时间】:2012-04-03 13:44:46
【问题描述】:

我有一个由 2 个应用程序生成的核心转储 -> /usr/bin/python 和 /usr/bin/app1。 我知道转储可以通过

进行分析
    gdb /path/to/app /path/to/core  

但是有没有办法在争论中包含这两个应用程序?

我确实尝试过 gdb '/usr/bin/python /usr/bin/app1' core.xxx 但这似乎不对。

有什么建议吗?

【问题讨论】:

    标签: gdb coredump


    【解决方案1】:

    我认为您无法通过一次调用 gdb 来实现您想要的。但是您可以在不同的终端窗口中运行两次gdb。我不止一次这样做了,而且效果很好(当然除了你自己的大脑可能会稍微超负荷)。

    gdb 进程只能调试一个程序,一个已调试的进程或(用于事后调试)一个 core 文件。

    而给定的core 文件是由一个进程(不是多个)异常终止产生的,所以我不明白你的问题。

    显然,您在执行 python 时遇到了崩溃,这可能是由于您的错误 C 代码而导致的。我建议有一个可调试的 Python 变体,可能通过安装 python3-all-dbg 包或类似的东西,然后在其上使用 gdb。当然,在启用调试的情况下编译插入 Python 的 C 代码。也许你违反了 Python 垃圾收集器的一些不变量。

    【讨论】:

    • 当我尝试使用 gdb python core.xxx 调试核心文件时,我在调试器中看到一行显示 core generated by '/usr/bin/python /usr/bin/app1 '。我认为这意味着它是由 2 个进程生成的,但我开始认为 app1 恰好是一个 python 进程导致它生成这样的消息。
    • 不,gdb 只是向您显示了出错的整个命令行(从技术上讲,argv 数组传递给 Python 的 main)。只有一个进程产生了核心转储。
    猜你喜欢
    • 1970-01-01
    • 2023-03-28
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2012-12-30
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多