分叉进程中的共享库调试
在这种情况下如何调试共享库:
守护进程正在检查设置为运行的作业,如果找到一个,守护进程将分叉一个进程。此过程将执行 dlopen/dlsym 等来使用共享库。
共享库在我的控制之下,因此我可以放置一个带有调试信息的共享库。虽然守护进程不受我的控制,并且由于某种原因无法停止。守护进程中没有可用的调试信息。
这是我调试的方法: 启动gdb,附加到守护进程,将follow-fork-mode设置为“child”,在共享库的入口点设置断点。
但这不起作用。调试会话根本没有在我设置的断点处中断。 我使用 gdb 6.1.1。 谢谢。
How can I debug a shared library in the this case:
A daemon is checking which job is set to run, if find one, the daemon will fork a process. This process will do dlopen/dlsym etc to use the shared library.
The shared library is under my control so I can put one with debug information. While the daemon is not under my control and cannot be stopped for some reason. There is no debug info available in daemon.
Here is how I debug:
start gdb, attach to the daemon, set follow-fork-mode to "child", set a breakpoint with the entry point of shared library.
But it doesn't work. The debug session didn't break at the breakpoint i set at all.
I use gdb 6.1.1.
Thanks.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
您可以在此处放入一个临时变量,然后是无限循环:在
您尝试调试的函数中的某个位置调用
my_shared_loopy()
...重新编译您的共享库,然后在附加调试器时对于您正在调试的函数,它将挂在这段代码上...只需将loopy
的值设置为 0,然后继续调试。编辑:作为一个附加的助手,我通常放在
循环之前。另外,如果您不想意外消耗大量循环,请像这样使循环休眠:
当您附加 GDB 时,您很可能会处于休眠状态。执行以下操作即可退出:
You can put in a temporary variable here, followed by a infinite loop:
Call that
my_shared_loopy()
somewhere in the function you are trying to debug...recompile your shared library and then when the debugger gets attached to the function you are debugging, it will hang on this code...simply set the value ofloopy
to 0 and then continue on debugging.EDIT: As an added helper, I usually put
before the loop. Also, if you don't want to accidentally burn a lot of cycles, make the loop sleep like this:
When you attach GDB, you'll most likely be inside sleep. Do this to get out:
我不知道这是否有帮助,但是在 Windows 中,当我遇到这样的问题时,我只需将以下代码插入到我的 dll 中的某个早期调用的方法中。
int 3
是 x86 CPU 的硬件中断指令然后,当加载我的 dll 时,此代码会被命中。 Windows 会弹出“你想调试你的应用程序吗”对话框,我说“是”。一旦调试器运行,我将
breakHere
更改为 true 并开始运行。I don't know if this helps, but in Windows, when I have problems like this, I just insert the following code into my dll in some method that is called early.
int 3
is the hardware break instruction for x86 CPUsThen when my dll is loaded and this code gets hit. Windows brings up the "Do you want to debug your application" dialog and I say yes. Once I have the debugger running, I change
breakHere
to true and go.