[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#4437: 23.1.50; Quitting gdb leaves a process behind
From: |
Hannu Koivisto |
Subject: |
bug#4437: 23.1.50; Quitting gdb leaves a process behind |
Date: |
Fri, 18 Sep 2009 15:44:10 +0300 |
User-agent: |
Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux) |
nickrob@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