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

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 10933 in the body.
You can then email your comments to 10933 AT debbugs.gnu.org in the normal way.

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

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

From: Rolando Pereira <ei08150 <at> fe.up.pt>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.0.94;
	No output shown in *input/output* buffer of M-x gdb not working after
	first run
Date: Sat, 03 Mar 2012 23:29:55 +0000

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)

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

From: Rolando Pereira <ei08150 <at> fe.up.pt>
To: 10933 <at> debbugs.gnu.org
Subject: Re: bug#10933: Acknowledgement (24.0.94;
	No output shown in *input/output* buffer of M-x gdb not working after
	first run)
Date: Mon, 05 Mar 2012 00:09:55 +0000

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

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

From: Troels Nielsen <bn.troels <at> gmail.com>
To: Rolando Pereira <ei08150 <at> fe.up.pt>
Cc: 10933 <at> debbugs.gnu.org
Subject: Re: bug#10933: Acknowledgement (24.0.94; No output shown in
	*input/output* buffer of M-x gdb not working after first run)
Date: Thu, 22 Mar 2012 10:30:32 +0100

[Message part 1 (text/plain, inline)]

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

[gdb-fix.patch (text/x-patch, attachment)]

Message #18 received at 10933-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Troels Nielsen <bn.troels <at> gmail.com>
Cc: Rolando Pereira <ei08150 <at> fe.up.pt>, 10933-done <at> debbugs.gnu.org
Subject: Re: bug#10933: Acknowledgement (24.0.94;
	No output shown in *input/output* buffer of M-x gdb not working after
	first run)
Date: Fri, 23 Mar 2012 08:27:26 -0400

> 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

Message #19 received at 10933-done <at> debbugs.gnu.org (full text, mbox):

From: Troels Nielsen <bn.troels <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Rolando Pereira <ei08150 <at> fe.up.pt>, 10933-done <at> debbugs.gnu.org
Subject: Re: bug#10933: Acknowledgement (24.0.94; No output shown in
	*input/output* buffer of M-x gdb not working after first run)
Date: Fri, 23 Mar 2012 13:50:12 +0100

Stefan Monnier writes:
 > > 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).

I think the problems mentioned in the comments are due to SIGCHLD
sometimes getting lost on certain unices, when two children or more
exit (or maybe generally when many signals are sent) simultaneously.

I believe (but may be mistaken :) ) that it is only relevant when
emacs itself is responsible for parenting the process. In this case
however gdb-mi is only creating a pty (using create_pty in process.c),
which gdb is instructed to connect the debugged process to. So gdb is
the parent and emacs should probably not care too much if the
debugged process dies.

Troels

Previous Next

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