On 10/27/07, ed <[EMAIL PROTECTED]> wrote: > > On Wed, 24 Oct 2007 09:03:20 -0400 > "Brett McCoy" <[EMAIL PROTECTED]> wrote: > > > This is somewhat off-topic here, you may want to talk to a Linux list > > for better answers. > > > > > I am writing an application in Linux OS using C++. It is getting > > > killed in a mysterious way during interactions with a removable > > > storage media. I wrote a signal handler for all the possible Linux > > > signals, but signal handler is not getting called. > > > > It's possible the program is crashing and not being killed in the > > normal fashion > > > > > To solve this problem, I want to know these things with respect to > > > Linux OS: > > > > > > 1) Is it possible to kill a process without sending any signal to > > > it? > > > > Well, a process can be killed by something bad like a segmentation > > fault or similar extreme situation. > > > > > 2) If answer to 1 is yes, how to kill without sending any signal? > > > 3) If answer to 1 is yes, how can the process getting killed know > > > the way in which it is being killed? > > > > There are several signals that are used to kill a process -- SIGQUIT, > > SIGTERM, SIGKILL, SIGABORT are the main ones. SIGSEGV, SIGFPE, SIGILL > > can also bring a program to its knees. SIGKILL is the only one you > > can't catch or ignore. > > > > > 4) If I kill a process by sending SIGKILL to that process, is there > > > any way for that process to know that it got killed by SIGKILL? > > > > No, you can't catch or ignore SIGKILL (signal 9). > > > > > 5) What other debugging methods can I follow to know the reason for > > > crash? (I can't obtain core dump or run debugger due to hardware > > > limitations. I can get log statements) > > > > What hardware limitations? If you can't use a debugger or use a core > > dump, then you will have to debug by logging the internal state of the > > program. > > Sorry, just being finicky, but there is a situation where the signal > will not be handled and the process will not be killed. It can be in > state uninteruptable and then the only way to forcefully remove it is > to reboot. > > There is a possibility that sending it OOM with magic sysreq could be > of assistance, but that's not certain to kill it off. > > -- > The dual T1 to the PS2 is toast because of a mistake. > The Empire is port scanning the entire /16. > :: http://www.s5h.net/ :: http://www.s5h.net/gpg > > > [Non-text portions of this message have been removed]
Thanks Brett and Ed, My process is getting killed. I guess its because of SIGKILL. I am not able to do clean-up operation. Because of this, other programs depending on my program behave abnormally. I am still trying to slove this problem. -Vijay [Non-text portions of this message have been removed]
