This is the gdb backtrace.
^C
Program received signal SIGINT, Interrupt.
0xffffe424 in __kernel_vsyscall ()
(gdb) bt
#0 0xffffe424 in __kernel_vsyscall ()
#1 0xb7e56a70 in __nanosleep_nocancel () from /lib/libc.so.6
#2 0xb7e568bb in __sleep (seconds=0) at sleep.c:138
#3 0x080496d5 in apSleep (msec=20) at xyz.c:10
Any clues?
Hello dragon,
Do you have access to the source ? If yes, can you post if over here (only the relevant part) ..
Thanks,
Gaurav.
Are you blocking SIGALRM? sleep usually works by setting a timer, then sending a SIGALRM signal to the calling process.
That's normally no longer true.
And in this case, its pretty likely that sleep() has been implemented with a version of nanoslee().
It would be nice to see what the actual source code is, though.
If you look, it appears as if the file "sleep.c" calls __nanosleep_nocancel() directly. That could be something in the way libc actually links in nanosleep(), but maybe not? And if what's supposed to be an internal call is being used incorrectly, maybe the sleep time is a very large 64-bit integer - and the call does have "nocancel" appended to it....
I had the code running on the system, before enabling hyperthreading. Does HT/ SMP have any side effects? I am not using any pthread libs either.
PS:
I apologize, i couldn't get access to the code since its on my work m/c and am at home. I will try to get some snippets posted tomoro.
Hi,
From the man page -
SIGINT is sent when the user on the process' controlling terminal presses the interrupt the running process key - typically Control-C, but on some systems, the "delete" character or "break" key.
So how come is that case even possible on its own ? Please correct me if I am wrong.
Thanks,
Gaurav.
I do believe he actually did hit control-C, to kill the program after it hanged. But sigint can also be sent by the kill utility and/or system call if you're curious.
Or if you're asking how ctrl-c sends an interrupt, the kernel does that for you, it's an ordinary property of terminal devices.