bug#11273: 24.0.94; quitting gdb

[Chong Yidong]

Sam Steingold <sds@gnu.org> writes:

> I start gdb on an interactive process (clisp) which I then exit.
> Now, I quit gdb too, but I am still left with a bunch of gdb windows and
> emacs running at 100% cpu because
> (process-status "gdb-inferior")
> => run
> even though it actually does not run (according to ps).
> (delete-process "gdb-inferior") fixes that, but this should not be
> necessary.
>
> 1. BUG: even though the gdb-inferior process is not running, it is
> reported as running and emacs takes 100% cpu.

This seems to be a combination of two bugs in the process code.

The situation is as follows: gdb-mi creates a pty process in the
"gdb-inferior" buffer, and hooks that pty up to the main gdb process.

The first bug is that it's necessary to explicitly call delete-process
on pty processes.  The gdb-mi code did not explicitly do this.
Normally, when you kill a buffer Emacs offers to kill its processes, but
this is ineffective for ptys, as the kill_buffer_processes() code calls
kill-process, not delete-process.  You can show this problem with the
following code unrelated to gdb:

  M-: (start-process "foo" (current-buffer) nil) RET
  C-x k RET yes RET
  M-x list-processes RET

Even though the pty's buffer is killed, and the user was prompted
whether to kill the process and answered yes, the pty is still
"running".

I don't know whether we should fix this general bug for 24.1---Stefan,
any opinion?

In the meantime, I installed a workaround to explicitly call
delete-process on the pty in the sentinel of the main gdb process.


Here is the second bug.  Uunder some circumstances, when the gdb process
exits, the sentinel doesn't get run.  You can see this by instrumenting
the `gud-sentinel' function, starting `M-x gdb', issuing an "r" command,
then "q".  The sentinel is never called, even though list-processes
confirms that the gdb process is now dead.  I have no idea why this
happens, but according to a debugging session it appears that the
select() call in process.c:4457 always returns a value >=0, so that
status_notify() is never called.  Maybe this has to do with the presence
of the gdb-inferior pty?