Find what interrupts sleep()

Question

Is there any way to find what where the signal that interrupted a call to sleep() came from?

I have a ginormous amount of code, and I get this stacktrace from 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

I'm not entirely sure what all the code does, but I think this is what is going on:

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

Answer 1

Find what interrupts sleep

At the time you attached GDB to the program, the sleep was in fact not interrupted by anything -- your stack trace indicates that your program is still blocked in the sleep system call.

Answer 2

If you are attaching to a running process, the process is interrupted by GDB itself to allow you to debug. The stack trace you observe is simply the stack of the running process at the time you attached to it. sleep() would not be an unreasonable system call for the process to be in when you are attaching to a process that appears to be idle.

If you are debugging a core file that shows the stack trace in sleep() , then when you start GDB to load a core file, it will display the top of the current stack frame of the core file. But just above that, it shows the signal that caused the core file. I wrote a test program, and this is what it showed when I loaded the core file into GDB:

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

A core file is just a process snapshot, it is not always due to an internal error from the code. Sometimes it is generated by a signal delivered from an external program or the shell. Sometimes it is generated by executing the command generate-core-file from within GDB. In these cases, your core file may not actually point to anything wrong, but just the state the program was in at the time the core file was created.

Answer 3

Do you know what the sleep address is inside setup()? For example, sleep(&variable). Look for all callers of wakeup(&variable) and one of them is the sleep breaker. If there are too many, then I would add a trace array to remember the wakeups that were issued ie just store the PC from where wakeup was called...you can read that in the core file.

If you are sure that the sleep is interruptible && the sleep was actually interrupted, then I would do what one other poster said...catch the signal in a signal handler, capture signal info and re-arm it with the same signal.