This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: fix problems with errors during quitting (killed.exp)


Daniel Jacobowitz wrote:
On Fri, Sep 05, 2003 at 11:53:55AM -0400, J. Johnston wrote:

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?


My immediate concern is, does killed.exp leave a stopped binary around?


It doesn't, but the debugged process going away was the cause of the error in the first place. I don't know if there are can't-quit scenarios where a process will be left around. Some fork/exec nightmare perhaps??, but I'm not sure what gdb could be expected to do in such a situation.

-- Jeff J.

Other than that I like it.


2003-09-04 Jeff Johnston <jjohnstn@redhat.com>

	* 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.





Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]