Following is the message as I originally posted it.
----------
I'm porting to Linux a hardware debugger we first created for a DOS Extender
-based system with DPMI. Overall, the conversion has gone quite well; I can
manipulate PCI space, tweak I/O ports, map and manipulate physical memory and
so forth.
However, I have had one nagging issue which has caused me great annoyance.
Whenever I get a segmentation fault, I expect it to take a core dump and
terminate. That's not what happens. Instead, the process appears to hang;
it is unresponsive to keystrokes. If I pop to another virtual terminal,
killing the process has no effect. "ps" shows it in status "D", which is an
uninterruptable I/O sleep state. The file "core" is created, but is zero
length.
If I run the exact same series of operations with the program in gdb, gdb
correctly traps the segmentation fault. It's only when the program is run
standalone that I have trouble. This has happened consistently in several
different cases of segmentation faults.
The reason this is particularly annoying is that, because the process is
apparently trying to manipulate the "core" file, the system is unable to
cleanly unmount the root file system at shutdown time, thus causing me to
suffer through an fsck on the next reboot.
Are segmentation faults handled differently in suid root processes? My next
adventure will be to add a SIGSEGV handler myself, although I'm not quite
sure what my recovery strategy could be...
-- - Tim Roberts, timr@probo.com Providenza & Boekelheide, Inc.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/