bug#10933: 24.0.94; No output shown in *input/output* buffer of M-x gdb not working after first run

bug#10933: 24.0.94; No output shown in *input/output* buffer of M-x gdb not working after first run

[Rolando Pereira]

Hello all,

There seems to be a problem with M-x gdb in the lastest version of emacs
(compiled from the bazaar repository).

When I run M-x gdb on some file, I get a *gud-foo* buffer as expected.

If I type "run" in that buffer, I get an additional buffer called
*input/output of foo* where the program writes it's output and I can
give inputs to it.

So far, everything is working as expected.

The bug appears after the program being debugged ends.

If I try to run the same program from the *gud-foo* buffer (by typing
"run" in it), the *input/output of foo* buffer no longer shows any
output.

However the buffer is still processing my input, because if I change the
code so that it writes to a file, the values written to it are the
values I type in the *input/output of foo* buffer.

So only the output is affect by this bug.


A couple of interesting notes:

* If I quit (by typing "quit" at the *gud* buffer) and start a new one,
  the bug is still in effect, ie. not even the first "run" works
  correctly. This problem appears to happen because the *input/output*
  buffer isn't correctly killed. It might be related to bug #6962: GDB
  hangs ( http://comments.gmane.org/gmane.emacs.bugs/39877 ) because
  even after I quit gdb, M-x list-process still shows a "gdb-inferior"
  process running.

  If I kill the "gdb-inferior" that's left behind, for example, with the
  following code:

  (dolist (process (process-list))
    (when (string= "gdb-inferior" 
                   (substring (process-name process) 0 12))
      (delete-process process)))

  I can start a new gdb and run the program once without any problems.

* This bug is *not* present in Emacs 23.3.1 (the lastest non-emacs-24 I
  have installed).
  In that version, both M-x gdb and M-x gud-gdb work correctly.


This is the C file I used as a test:

--8<---------------cut here---------------start------------->8---
#include <stdio.h>

int main() {
	int foo = 0;
	int bar = 0;

	printf("foo: ");
	scanf("%d", &foo);

	printf("foo is: %d\n", foo);

	printf("bar: ");
	scanf("%d", &bar);

	printf("bar is: %d\n", bar);

	FILE *file = fopen("test.txt", "w");
	fprintf(file, "foo: %d\nbar: %d", foo, bar);
	fclose(file);
	
	return 0;
}
--8<---------------cut here---------------end--------------->8---



Here are the steps to reproduce the bug starting from "emacs -Q".

1. After opening emacs, open the file with the code (I'm going to assume
it's called "main.c")

2. Compile it with M-x compile with the command "gcc -o main -g main.c".

3. Type M-x gdb with the command "gdb -i=mi main".

4. In the *gud-main* buffer type "run".
   
5. In the *input/output of main* type "1" (without the quotes) in front
of "foo: ". Press enter.

6. Type "2" (without the quotes) in front of "bar: ". Press enter.

7. Notice that there were no problems with the program execution.

8. Go to the *gud-main* buffer. Type "run" in it.

9. Notice that the string "foo: " no longer appears. Type "10" (without
   the quotes).

10. Notice that "bar: " also doesn't appear. Type "20" (without the
quotes).

11. Notice that the program ended (the *gud-main* shows
[existed-normally]).

12. Open the "test.txt" file. It should have the following content:
    foo: 10
    bar: 20




In GNU Emacs 24.0.94.1 (i686-pc-linux-gnu, GTK+ Version 2.20.1)
 of 2012-03-03 on rolando-desktop
Windowing system distributor `The X.Org Foundation', version 11.0.10706000
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: pt_PT.utf8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Debugger

Minor modes in effect:
  shell-dirtrack-mode: t
  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
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
o m p i l e <return> <M-backspace> <M-backspace> g 
+ + <backspace> <backspace> c c SPC - o SPC m a i n 
SPC - g SPC m a i n . c <return> M-x g d b <return> 
<return> r <return> 3 5 <return> C-x o 3 5 6 <backspace> 
<backspace> <backspace> 1 <return> 3 <return> C-x o 
r <return> C-x o 3 5 2 <backspace> <backspace> <backspace> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <tool-bar> <current-thread> <help-echo> 
<tool-bar> <all-threads> <help-echo> <tool-bar> <current-thread> 
<help-echo> <help-echo> <tool-bar> <stop> <help-echo> 
<tool-bar> <all-threads> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
3 5 <return> 2 3 <return> 2 <backspace> <backspace> 
C-x o y <return> y <return> y <return> <return> <return> 
<return> y e s <return> n <return> y <return> y <return> 
y <return> y <return> y <return> y <return> y <return> 
y <return> y <return> y <return> y <return> n <return> 
<f3> <f3> <f4> <f4> C-x k <return> t <backspace> y 
e s <return> C-x o C-x k <return> M-x l i s t - p r 
o c e s s <return> C-x o C-x b <return> M-x g d b <return> 
<return> r <return> C-x o 5 <return> 2 3 <return> C-x 
o r <return> C-x o 3 5 <return> 2 3 5 <return> C-x 
o q u i t <return> y e s <return> M-x l i s t - p r 
o c e s s <return> C-x o M-x e m a <backspace> <backspace> 
<backspace> r e p o r t - <tab> <return> C-g M-x g 
d b <return> <return> r <return> r <return> C-x k <return> 
y e s <return> y e s <return> C-x o M-x <up> <return> 
<return> r <return> M-x r e p o r <tab> <return>

Recent messages:
Command: -exec-interrupt
Now in non-stop/A mode.
Defining kbd macro...
New macro counter value: 1 (1)
Keyboard macro defined
Quit
Nenhum arquivo executável especificado.
Utilize o comando "file" ou "exec-file".
Nenhum arquivo executável especificado.
Utilize o comando "file" ou "exec-file".

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev
gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util
mail-prsvr mail-utils tabulated-list kmacro gdb-mi bindat json gud
easy-mmode shell pcomplete compile comint ansi-color ring cc-mode
cc-fonts easymenu cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine
cc-vars cc-defs regexp-opt time-date tooltip ediff-hook vc-hooks
lisp-float-type mwheel x-win x-dnd tool-bar dnd fontset image fringe
lisp-mode register page menu-bar rfn-eshadow timer select scroll-bar
mouse jit-lock font-lock syntax facemenu font-core frame cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev
minibuffer loaddefs button faces cus-face files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process dbusbind
dynamic-setting system-font-setting font-render-setting move-toolbar gtk
x-toolkit x multi-tty emacs)

bug#10933: Acknowledgement (24.0.94; No output shown in *input/output* buffer of M-x gdb not working after first run)

[Rolando Pereira]

Just a little more information about the bug that I gathered today:

1. Ending the execution of the program being debugged by calling
`gdb-io-interrupt' (C-c C-c) when the cursor is in front of the "foo: "
or "bar: " prompts stops the bug from occuring.

2. The same thing happens when you call `comint-interrupt-subjob' in the
*gud-main* buffer.

3. If I start gdb with M-x gud-gdb, everything works fine (I thought the
gud-gdb wasn't part of emacs 24, so I hadn't tested it).

I forgot to mention in the first email that I'm running gdb 7.4, but the
bug also happens with gdb 7.2

bug#10933: Acknowledgement (24.0.94; No output shown in *input/output* buffer of M-x gdb not working after first run)

[Troels Nielsen]

[-- Attachment #1: Type: text/plain, Size: 294 bytes --]

Hi,

I think this bug is due to gdb-mi creating a pty which it expects to
remain open. When the process being debugged disconnects, emacs will
receive an EIO-errno and (I believe mistakenly) send a SIGCHLD to
itself, and stop listening to the pty.

This patch fixes the problem for me.

Troels

[-- Attachment #2: gdb-fix.patch --]
[-- Type: text/x-patch, Size: 959 bytes --]

=== modified file 'src/process.c'
--- src/process.c	2012-01-21 10:54:19 +0000
+++ src/process.c	2012-03-21 22:16:02 +0000
@@ -4888,11 +4888,14 @@
 		 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);
+                  /* Don't do anything if only a pty, with no associated process */
+                  if (XPROCESS(proc)->pid != -2) { 
+                    /* 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

bug#10933: Acknowledgement (24.0.94; No output shown in *input/output* buffer of M-x gdb not working after first run)

[Stefan Monnier]

> I think this bug is due to gdb-mi creating a pty which it expects to
> remain open. When the process being debugged disconnects, emacs will
> receive an EIO-errno and (I believe mistakenly) send a SIGCHLD to
> itself, and stop listening to the pty.

> This patch fixes the problem for me.

Thanks, I don't understand what is special about gdb-mi that it's the
only one to trigger this problem, and I suspect there's a slightly
cleaner fix (as the above comment mentions, we only send ourselves
a SIGCHLD to work around problems we don't understand in some
undescribed situations, which may even be situations that don't exist
any more nowadays for all I know).
But I installed the patch anyway, with minor coding-convention cleanups
(wrap at 80 columns, space before open-paren).


        Stefan