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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 4437 in the body.
You can then email your comments to 4437 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Hannu Koivisto <azure <at> iki.fi>
To: emacs-pretest-bug <at> gnu.org
Subject: 23.1.50; Quitting gdb leaves a process behind
Date: Mon, 14 Sep 2009 23:54:48 +0300

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

Message #10 received at 4437 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: nickrob <at> snap.net.nz (Nick Roberts)
To: Hannu Koivisto <azure <at> iki.fi>, 4437 <at> debbugs.gnu.org
Cc: emacs-pretest-bug <at> gnu.org
Subject: bug#4437: 23.1.50; Quitting gdb leaves a process behind
Date: Wed, 16 Sep 2009 14:00:10 +1200

 > 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

Message #20 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

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: Re: 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

Message #30 received at 4437 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: nickrob <at> snap.net.nz (Nick Roberts)
To: Hannu Koivisto <azure <at> iki.fi>
Cc: 4437 <at> debbugs.gnu.org, emacs-pretest-bug <at> gnu.org
Subject: Re: bug#4437: 23.1.50; Quitting gdb leaves a process behind
Date: Tue, 22 Sep 2009 17:36:05 +1200 (NZST)

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

Message #38 received at 4437 <at> debbugs.gnu.org (full text, mbox):

From: Chong Yidong <cyd <at> gnu.org>
To: Hannu Koivisto <azure <at> iki.fi>
Cc: 4437 <at> debbugs.gnu.org
Subject: Re: bug#4437: 23.1.50; Quitting gdb leaves a process behind
Date: Fri, 20 Apr 2012 14:40:48 +0800

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.

Previous Next

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