* bug#4437: 23.1.50; Quitting gdb leaves a process behind
@ 2009-09-14 20:54 Hannu Koivisto
2009-09-16 2:00 ` Nick Roberts
2012-04-20 6:40 ` Chong Yidong
0 siblings, 2 replies; 5+ messages in thread
From: Hannu Koivisto @ 2009-09-14 20:54 UTC (permalink / raw
To: emacs-pretest-bug
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''
Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: nil
value of $LC_CTYPE: fi_FI@euro
value of $LC_MESSAGES: nil
value of $LC_MONETARY: nil
value of $LC_NUMERIC: nil
value of $LC_TIME: nil
value of $LANG: POSIX
value of $XMODIFIERS: nil
locale-coding-system: iso-latin-9-unix
default enable-multibyte-characters: t
Major mode: Debugger
Minor modes in effect:
tooltip-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
global-auto-composition-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t
Recent input:
M-x g d b <return> <return> q u i t <return> y e s
<return> M-x l i s t - p r <tab> <return> C-x 5 2 <switch-frame>
M-x r e p o r t - e m <tab> <return>
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
This version of GDB doesn't support non-stop mode. Turning it off.
Load-path shadows:
None found.
--
Hannu
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#4437: 23.1.50; Quitting gdb leaves a process behind
2009-09-14 20:54 bug#4437: 23.1.50; Quitting gdb leaves a process behind Hannu Koivisto
@ 2009-09-16 2:00 ` Nick Roberts
2009-09-18 12:44 ` Hannu Koivisto
2012-04-20 6:40 ` Chong Yidong
1 sibling, 1 reply; 5+ messages in thread
From: Nick Roberts @ 2009-09-16 2:00 UTC (permalink / raw
To: Hannu Koivisto, 4437; +Cc: emacs-pretest-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.
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.
Similar problems were reported as part of bug#4375. I'm still looking in
to it.
--
Nick http://www.inet.net.nz/~nickrob
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#4437: 23.1.50; Quitting gdb leaves a process behind
2009-09-16 2:00 ` Nick Roberts
@ 2009-09-18 12:44 ` Hannu Koivisto
2009-09-22 5:36 ` Nick Roberts
0 siblings, 1 reply; 5+ messages in thread
From: Hannu Koivisto @ 2009-09-18 12:44 UTC (permalink / raw
To: Nick Roberts; +Cc: 4437, emacs-pretest-bug
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#4437: 23.1.50; Quitting gdb leaves a process behind
2009-09-18 12:44 ` Hannu Koivisto
@ 2009-09-22 5:36 ` Nick Roberts
0 siblings, 0 replies; 5+ messages in thread
From: Nick Roberts @ 2009-09-22 5:36 UTC (permalink / raw
To: Hannu Koivisto; +Cc: 4437, emacs-pretest-bug
> > 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.
> 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 think this is related to the change I made to process.c below. This allows
the I/O buffer to work when the inferior is restarted but means that
status_notify isn't called from wait_reading_process_output because this call
is conditioned on select which returns a positive value (presumably because the
pty's file descriptor hasn't been cleared). Reverting it means processes aren't
left lying around but that leaves the original problem.
I mention this in case someone who knows process.c better than me can see a
way around it.
--
Nick http://www.inet.net.nz/~nickrob
Index: process.c
===================================================================
RCS file: /sources/emacs/emacs/src/process.c,v
retrieving revision 1.594
retrieving revision 1.595
diff -c -p -r1.594 -r1.595
*** process.c 27 Aug 2009 11:12:54 -0000 1.594
--- process.c 30 Aug 2009 04:54:34 -0000 1.595
*************** wait_reading_process_output (time_limit,
*** 5150,5160 ****
It can't hurt. */
else if (nread == -1 && errno == EIO)
{
! /* Clear the descriptor now, so we only raise the signal once. */
! FD_CLR (channel, &input_wait_mask);
! FD_CLR (channel, &non_keyboard_wait_mask);
! kill (getpid (), SIGCHLD);
}
#endif /* HAVE_PTYS */
/* If we can detect process termination, don't consider the process
--- 5150,5165 ----
It can't hurt. */
else if (nread == -1 && errno == EIO)
{
! /* Clear the descriptor now, so we only raise the
! signal once. Don't do this is `process' is only
! a pty. */
! if (XPROCESS (proc)->pid != -2)
! {
! FD_CLR (channel, &input_wait_mask);
! FD_CLR (channel, &non_keyboard_wait_mask);
! kill (getpid (), SIGCHLD);
! }
}
#endif /* HAVE_PTYS */
/* If we can detect process termination, don't consider the process
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#4437: 23.1.50; Quitting gdb leaves a process behind
2009-09-14 20:54 bug#4437: 23.1.50; Quitting gdb leaves a process behind Hannu Koivisto
2009-09-16 2:00 ` Nick Roberts
@ 2012-04-20 6:40 ` Chong Yidong
1 sibling, 0 replies; 5+ messages in thread
From: Chong Yidong @ 2012-04-20 6:40 UTC (permalink / raw
To: Hannu Koivisto; +Cc: 4437
Hannu Koivisto <azure@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 raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2012-04-20 6:40 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-09-14 20:54 bug#4437: 23.1.50; Quitting gdb leaves a process behind Hannu Koivisto
2009-09-16 2:00 ` Nick Roberts
2009-09-18 12:44 ` Hannu Koivisto
2009-09-22 5:36 ` Nick Roberts
2012-04-20 6:40 ` Chong Yidong
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.