Mail Archives: djgpp/1999/02/02/11:27:39
At 10:46 AM 2/2/99 -0500, you wrote:
>No, SIGKILL is the only signal a process can't catch, so it's the
>"kill of last resort" to try to end a process. SIGKILL can only be
>sent, not trapped. The kill() function can send *any* signal to a
>process.
A parent can use WIFSIGNALED and WTERMSIG to spot a SIGKILL kill of a child
though right?
>> SIGQUIT -- ???
>
>Not sure about this one, but I think it can sometimes be generated
>from the keyboard under Unix.
Other sources have informed me that this is true, and that it's sometimes
used in interpreters where you want SIGINT to be a user interrupt of the
interpreted code, and SIGQUIT can be used for a kind of "instant
breakpoint" to drop into the debugger. Sounds nice. I remember debugging
tons of QBASIC and having to add keypress checks for some key everywhere to
issue "STOP", which in QBASIC drops into the debugger for inspecting or
modifying things, resuming, or quitting.
>> SIGTERM -- ???
>
>Ctrl-C generates this.
Erm, Ctrl-C generated SIGINT.
>> SIGILL -- ???
>
>This usually implies that the CPU has attempted to execute an
>ill-formed opcode, like random garbage.
Most likely caused by inept inline asm or by a jump through a bad pointer
that doesn't segfault, perhaps because you jumped into the middle of your
own data, an array of ints perhaps or a string constant. :-)
Other possibility: a buggy assembler... something I doubt will occur with
DJGPP.
--
.*. "Clouds are not spheres, mountains are not cones, coastlines are not
-() < circles, and bark is not smooth, nor does lightning travel in a
`*' straight line." -------------------------------------------------
-- B. Mandelbrot |http://surf.to/pgd.net
_____________________ ____|________ Paul Derbyshire pderbysh AT usa DOT net
Programmer & Humanist|ICQ: 10423848|
- Raw text -