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

[nickrob@snap.net.nz (Nick Roberts)]

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