headers
Hannu Koivisto | 14 Sep 2009 22:54
Picon
Picon
Favicon

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

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

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.

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.

In GNU Emacs 23.1.50.1 (x86_64-unknown-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2009-09-13 on deliverance
Windowing system distributor `The X.Org Foundation', version 11.0.10400090
configured using `configure  '--prefix=/usr/local' '--with-x-toolkit=athena''
(Continue reading)

Permalink | Reply |
headers
Nick Roberts | 16 Sep 2009 04:00
Picon

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

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

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.
(Continue reading)

Permalink | Reply |
headers
Hannu Koivisto | 18 Sep 2009 14:44
Picon
Picon
Favicon

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

nickrob <at> snap.net.nz (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
(Continue reading)

Permalink | Reply |
headers
Nick Roberts | 22 Sep 2009 07:36
Picon

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

 > > 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?  

No.  I mean there's generally no need to type 'quit' in the GUD buffer.
I've reverted an inadvertant change, so any recent problems (last few
days) should disappear.  It's still not ideal and you can find further
problems if you look for them

 >           Sure.  I can even restart Emacs, I have no problem living
 > with the problem till it gets fixed.

It should now be enough to kill the GUD buffer.

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

I think it might be hard to implement.  GDB has it's own history on the
command line using:

set history save on

Now Emacs uses GDB/MI, commands from the GUD buffer don't go into that
history so Emacs would need to emulate GDB's behaviour.
(Continue reading)

Permalink | Reply |
headers
Chong Yidong | 20 Apr 2012 08:40
Picon

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

Hannu Koivisto <azure <at> iki.fi> 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 

This is fixed in the emacs-24 branch.  Closing.
Permalink | Reply |

Gmane