【问题标题】:Shared library debug in forked process分叉进程中的共享库调试
【发布时间】:2010-02-11 00:50:43
【问题描述】:

在这种情况下如何调试共享库:

一个守护进程正在检查哪个作业被设置为运行,如果找到一个,守护进程将派生一个进程。此过程将执行 dlopen/dlsym 等操作以使用共享库。

共享库在我的控制之下,所以我可以放一个带有调试信息的库。虽然守护进程不受我的控制,并且由于某种原因无法停止。守护进程中没有可用的调试信息。

这是我的调试方式: 启动gdb,附加到守护进程,将follow-fork-mode设置为“child”,以共享库的入口点设置断点。

但它不起作用。调试会话并没有在我设置的断点处中断。 我使用 gdb 6.1.1。 谢谢。

【问题讨论】:

    标签: debugging gdb fork


    【解决方案1】:

    你可以在这里放入一个临时变量,然后是一个无限循环:

    无效 my_shared_loopy() { int 循环 = 1; 而(循环); }

    在您尝试调试的函数中的某处调用my_shared_loopy()...重新编译您的共享库,然后当调试器连接到您正在调试的函数时,它将挂在此代码上...只需设置loopy 的值改为 0,然后继续调试。

    编辑:作为一个附加的助手,我通常把

    fprintf(stderr, "attach GDB to %d\n", getpid());
    

    在循环之前。另外,如果您不想意外烧掉很多循环,请像这样让循环休眠:

    无效 my_shared_loopy() { int 循环 = 1; fprintf(stderr, "将 GDB 附加到 %d\n", getpid()); 而(循环)睡眠(1); }

    当您附加 GDB 时,您很可能处于睡眠状态。这样做出去:

    (gdb) finish
    (gdb) set var loopy = 0
    (gdb) break <wherever you want to debug>
    (gdb) continue
    

    【讨论】:

    • @Employed 俄语 - 感谢您的小编辑! :)
    【解决方案2】:

    我不知道这是否有帮助,但是在 Windows 中,当我遇到这样的问题时,我只需通过一些提前调用的方法将以下代码插入到我的 dll 中。

    static bool breakHere = true;
    if (breakHere) _asm {int 3}
    

    int 3 是 x86 CPU 的硬件中断指令

    然后当我的 dll 被加载并且这个代码被命中时。 Windows 弹出“你想调试你的应用程序”对话框,我说是。调试器运行后,我将 breakHere 更改为 true 并运行。

    【讨论】:

    • 问题没有说明操作系统和处理器; “int 3”(或 UNIX 汇编器拼写为“int3”)假设这是在 Intel x86 上,但我们不知道。此外,此方法会在进程未在调试器下执行时崩溃和烧毁。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2011-06-29
    • 2014-04-15
    • 1970-01-01
    • 1970-01-01
    • 2013-10-12
    相关资源
    最近更新 更多