Messages in this thread | | | From | "Tim Roberts" <> | Date | Tue, 17 Aug 1999 09:46:07 -0700 | Subject | Segmentation fault causes stuck-in-D-state? |
| |
I sent this originally to the comp.os.linux.development.system newsgroup. Someone there suggested I forward it to the linux-kernel mailing list. He indicated there have been reports of processes stuck in D state (uninterruptable I/O sleep) which couldn't be reproduced. I believe I can consistently reproduce this condition on a 2.2.9 kernel. I have not subscribed to the mailing list, because I don't believe I would be a valuable contributor. If there is interest in pursuing this, please let me know.
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/
| |