是否可以将gdb附加到崩溃的进程（也就是“及时”调试） [英] Is it possible to attach gdb to a crashed process (a.k.a "just-in-time" debugging)

问题描述

当进程崩溃时，我希望可以在崩溃但未清除的状态下针对它调用gdb（或类似的调试器）。经常在事后评估核心转储会提供足够的信息，但有时我想进一步探索运行状态，可能会抑制即时故障并进一步运行。从一开始在gdb下运行该进程并不总是适当的（例如，调用复杂或错误对时间敏感的错误）

When a process crashes I want the possibility to invoke gdb (or a similar debugger) against it in that crashed-but-not-cleaned-up state. Often post-morteming a core dump gives enough information but sometimes I want to explore the running state further, possibly suppressing the immediate fault and running a little further. It isn't always appropriate to run the process under gdb from the outset (e.g. where the invocation is complex or the bug is absurdly timing-sensitive)

描述基本上是通过 AEDebug注册表项在MS Windows上公开的即时调试工具：在进行诊断时，将故障线程挂起。在非开发人员的Windows PC上，通常将其设置为崩溃诊断机制（以前称为 Dr Watson），对于该机器，Ubuntu等效项似乎是批准 。

What I'm describing is basically the just-in-time debugging facility that is exposed on MS Windows through the "AEDebug" registry key: leaving the faulting thread suspended while doing something diagnostic. On non-developer Windows PCs this is commonly set to a crash diagnostic mechanism (formerly "Dr Watson"), for which the Ubuntu equivalent seems to be "apport".

我确实找到了旧邮件线程（2007）提到此问题时不时弹出，因此它可能存在但以一种使我无法搜索的方式描述的问题？

I did find an old mail thread (2007) which refers to this question "popping up every now and then", so possibly it exists but described in a way that eludes my searches?

推荐答案

我不知道是否存在这样的功能，但是作为黑客，您可以LD_PRELOAD某些东西在SIGSEGV上添加一个调用 gdb ：

I don't know if such a feature exist, but as a hack, you could LD_PRELOAD something that adds a handler on SIGSEGV that calls gdb:

cat >> handler.c << 'EOF'
#include <stdlib.h>
#include <signal.h>
void gdb(int sig) {
  system("exec xterm -e gdb -p \"$PPID\"");
  abort();
}

void _init() {
  signal(SIGSEGV, gdb);
}
EOF
gcc -g -fpic -shared -o handler.so -nostartfiles handler.c

，然后运行以下应用程序：

And then run your applications with:

LD_PRELOAD=/path/to/handler.so your-application

然后，在SEGV上，它将运行 gdb 中的 xterm 。如果在此处执行 bt ，您会看到类似以下内容的信息：

Then, upon a SEGV, it will run gdb in a xterm. If you do a bt there, you'll see something like:

(gdb) bt
#0  0x00007f8c58152cac in __libc_waitpid (pid=8294,
    stat_loc=stat_loc@entry=0x7fffd6170e40, options=options@entry=0)
    at ../sysdeps/unix/sysv/linux/waitpid.c:31
#1  0x00007f8c580df01b in do_system (line=<optimized out>)
    at ../sysdeps/posix/system.c:148
#2  0x00007f8c58445427 in gdb (sig=11) at ld.c:4
#3  <signal handler called>
#4  strlen () at ../sysdeps/x86_64/strlen.S:106
#5  0x00007f8c5810761c in _IO_puts (str=0x0) at ioputs.c:36
#6  0x000000000040051f in main (argc=1, argv=0x7fffd6171598) at a.c:2

而不是运行 gdb ，您也可以暂停自己（ kill（getpid（），SIGSTOP ）或调用 pause（）在闲暇时自行启动 gdb 。

Instead of running gdb, you could also suspend yourself (kill(getpid(), SIGSTOP) or call pause() to start gdb yourself at your leisure.

如果应用程序本身安装SEGV处理程序还是setuid / setgid ...

That approach won't work if the application install a SEGV handler itself or is setuid/setgid...

这就是 @yugr 对于他的 libdebugme工具，您可以在此处使用它：

That's the approach used by @yugr for his libdebugme tool, which you could use here as:

DEBUGME_OPTIONS='xterm:handle_signals=1' \
  LD_PRELOAD=/path/to/libdebugme.so your-application

这篇关于是否可以将gdb附加到崩溃的进程（也就是“及时”调试）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！