0

有什么方法可以找到中断调用 sleep() 的信号来自哪里？

我有大量的代码，我从 gdb 得到这个堆栈跟踪：

#0  0x00418422 in __kernel_vsyscall ()
#1  0x001adfc6 in nanosleep () from /lib/libc.so.6
#2  0x001adde1 in sleep () from /lib/libc.so.6
#3  0x080a3cbd in MRT::setUp (this=0x9c679d8) at /code/Core/exec/mrt.cc:50
#4  0x080a1efc in main (argc=13, argv=0xbfcb6934) at /code/Core/exec/rpn.cc:211

我不完全确定所有代码的作用，但我认为这是正在发生的事情：

Program 1 starts
Calls program 2 for shared memory allocation
Waits predetermined amount of time for allocation to complete
Program 1 continues
4

3 回答 3

1

找出中断睡眠的原因

在您将 GDB 附加到程序sleep时，实际上并没有被任何东西中断——您的堆栈跟踪表明您的程序仍然被sleep系统调用阻塞。

于 2013-08-01T03:48:33.487 回答
0

如果您正在附加到正在运行的进程，则该进程会被 GDB 本身中断以允许您进行调试。您观察到的堆栈跟踪只是您附加到它时正在运行的进程的堆栈。sleep()当您附加到似乎空闲的进程时，该进程所在的系统调用不会是一个不合理的系统调用。

如果您正在调试显示堆栈跟踪的核心文件sleep()，那么当您启动 GDB 加载核心文件时，它将显示核心文件的当前堆栈帧的顶部。但就在此之上，它显示了导致核心文件的信号。我编写了一个测试程序，当我将核心文件加载到 GDB 中时，它显示了以下内容：

Core was generated by `./a.out'.
Program terminated with signal 11, Segmentation fault.
#0  0x0000000000400458 in main ()
(gdb)

核心文件只是一个进程快照，它并不总是由于代码的内部错误。有时它是由外部程序或外壳传递的信号生成的。generate-core-file有时它是通过在 GDB 中执行命令生成的。在这些情况下，您的核心文件可能实际上并没有指出任何错误，而只是在创建核心文件时程序所处的状态。

于 2013-07-31T20:28:45.580 回答
0

你知道 setup() 里面的 sleep 地址是什么吗？例如，睡眠（&变量）。查找所有调用 wakeup(&variable) 的调用者，其中之一是睡眠断路器。如果有太多，那么我会添加一个跟踪数组来记住发出的唤醒，即只存储调用唤醒的 PC……你可以在核心文件中读取它。

如果您确定睡眠是可中断的 && 睡眠实际上被中断了，那么我会按照另一位发帖人所说的做......在信号处理程序中捕获信号，捕获信号信息并用相同的信号重新武装它。

于 2013-07-31T20:47:51.073 回答