bug#4437: 23.1.50; Quitting gdb leaves a process behind

[email protected] (Nick Roberts) writes:

>  > Start emacs with -q option, start gdb to debug any program
>  > (M-x gdb RET C-a gdb -i=mi ./some-program), quit immediately by typing
>  > quit RET to gdb command line (and answer "yes" to the question
>  > whether to kill the process associated to the buffer) and finally list
>  > processes with M-x list-processes RET.
>  >
>  > Expected result: no processes.
>  > Actual result:
>  > 
>  > Proc	     Status   Buffer   Tty	   Command
>  > ----	     ------   ------   ---	   -------
>  > gdb-inferior run      (Killed) /dev/pts/15 
>  > 
>  > If I start gdb again after this, I get a new gdb-inferior<1>
>  > process which again is left running when I quit gdb.
>
> If you want to run the same, but possibly newly compiled executable it's
> generally best not to quit GDB.  GDB will automatically load the new code
> and it has the advantage of keeping shell history, breakpoints etc.  You
> may need to change the line numbers on some breakpoints if the surrounding
> code has changed. 

Did you mean to give this advice as a workaround for the leakage
problem?  Sure.  I can even restart Emacs, I have no problem living
with the problem till it gets fixed.

As a general comment to this history stuff, it wouldn't be a bad
feature if Emacs could provide history and breakpoint persistence
over gud/gdb sessions.

> If you want to run a different executable then it's best to kill the GUD
> buffer before starting a new session.

>  > I've also seen cases where "quit" command to gdb does absolutely
>  > nothing.  In at least some sub-cases, if I then say M-x list-processes
>  > RET, _then_ I get the question whether to kill the process associated to
>  > the buffer and if I say "yes", the debugger quits and I get "Debugger
>  > finished" in the gdb buffer.
>
> Similar problems were reported as part of bug#4375.  I'm still looking in
> to it.

I read through that bug entry some time ago (after I got your mail)
and I think I saw the process leakage being mentioned there, but I
don't think I saw this particular quit problem.  There were some
other quit problems, though, and maybe many of these are related.

For what it's worth, I now know how to reproduce this one.  All I
need to do in addition to what I did to reproduce the leakage
problem is to set a temporary breakpoint to main function and "run"
to it before invoking quit.

I forgot to mention that I'm using gdb 6.8.

-- 
Hannu