GNU bug report logs - #4437
23.1.50; Quitting gdb leaves a process behind

Previous Next

Package: emacs;

Reported by: Hannu Koivisto <azure <at> iki.fi>

Date: Mon, 14 Sep 2009 21:00:04 UTC

Severity: normal

Done: Chong Yidong <cyd <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Hannu Koivisto <azure <at> iki.fi>
To: nickrob <at> snap.net.nz (Nick Roberts)
Cc: 4437 <at> debbugs.gnu.org, emacs-pretest-bug <at> gnu.org
Subject: bug#4437: 23.1.50; Quitting gdb leaves a process behind
Date: Fri, 18 Sep 2009 15:44:10 +0300
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
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



This bug report was last modified 13 years and 113 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.