调试使用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 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屋！