The following patch fixes the problem that occurs when an error happens while quitting. Often an error() call gets triggered and the poor user is thrown back to the gdb command line where they try to quit again. I made an attempt to fix a similar problem by handling ptrace errors in quitting, however, thread-db.c gets into multiple precarious situations because it has to rely on libthread_db for information. When the thread has been killed/maimed, it gets errors when they are not expected and quitting becomes impossible. My new strategy is to intercept error() calls during quitting. Basically, a simple get/set function is set up to denote when we the user has confirmed a quit. If we get into top.c:throw_exception() and quit has been confirmed, it exits the program. This handles any number of messy kill scenarios and causes no regressions in the current testsuite. It fixes gdb.threads/killed.exp. I made the functions external so other parts of gdb can register a confirmed quit if necessary. I could make these routines static if this feature is not needed. I chose to exit with the code being passed on the jump. There may be a better constant choice. If anyone can think of scenario that this code is not going to handle correctly that might not be exercised by the testsuite, please let me know. Tested on x86 and ia64. Comments? 2003-09-04 Jeff Johnston * top.h (get_quit_confirmed, set_quit_confirmed): New prototypes. * top.c (get_quit_confirmed, set_quit_confirmed): New functions. (throw_exception): If quit confirmed, exit instead of jumping.