调试使用SIGINT和gdb的程序 [英] Debugging a program that uses SIGINT with gdb
问题描述
我经常使用PostgreSQL进行调试,并且它在内部使用 SIGINT
进行后端后端信令。
I frequently work with PostgreSQL for debugging, and it uses SIGINT
internally for some of its inter-backend signalling.
因此,在 gdb
下运行某些后端时,执行往往会中断很多。可以使用 signal
命令来确保将 SIGINT
传递给程序,并确保它不会被<$捕获。 c $ c> gdb ...,但是随后 gdb
不会在命令行上响应control-C,因为这会发送 SIGINT
。
As a result when running certain backends under gdb
execution tends to get interrupted a lot. One can use the signal
command to make sure SIGINT
is passed to the program and that it is not captured by gdb
... but then gdb
doesn't respond to control-C on the command line, since that sends SIGINT
.
如果您运行:
handle SIGINT noprint nostop pass
gdb
会抱怨
SIGINT is used by the debugger.
Are you sure you want to change it? (y or n) y
有没有办法让gdb使用不同的中断信号?还是让我 gdb
忽略 SIGINT
的任何其他方法?
Is there any way to get gdb to use a different interrupt signal? Or any alternative method that'd let me have gdb
ignore SIGINT
?
(对于大多数PostgreSQL后端调试而言,这不是问题,但是对于后台工作人员和自动清理是一个痛苦)。
(This isn't an issue for most PostgreSQL backend debugging, but it's a pain with background workers and autovacuum).
推荐答案
在类似UNIX的系统上,您可以通过查看 si_pid $来区分tty启动的SIGINT与
kill
发送的SIGINT。 siginfo 结构中的c $ c>元素。如果pid为0,则它来自tty。
On UNIX-like systems, you can distinguish a tty-initiated SIGINT from one sent by kill
by looking at the si_pid
element in the siginfo struct. If the pid is 0, it came from a tty.
所以您可以执行以下操作:
So you could do something like this:
catch signal SIGINT
commands
if $_siginfo._sifields._kill.si_pid == 0
print "Received SIGINT from tty"
else
printf "Received SIGINT from %d; continuing\n", $_siginfo._sifields._kill.si_pid
signal SIGINT
end
end
这篇关于调试使用SIGINT和gdb的程序的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!