bug#12163: 24.1; Can not input anything or showing none output when debugging c/c++ application.

bug#12163: 24.1; Can not input anything or showing none output when debugging c/c++ application.

[qq510371827]

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

I am running emacs 24.1 on windows7 32bit with mginw32.When debugging my
c/c++ application I can not give an iputting and can not see any
output. For example:
         ...          //  line 1
         ...          //  line 2
         fgets(s,255,stdin); //line 3
         ...         // line 4
         ...         //line 5
         i = 0; // line 6          Breakpoint is at this line.
Then i started debugging:
(gdb)r
After executing the above command, it stopped at line 6 and didn't
waitting for me to input values. I inputted values in input/output io
buffer but nothing happend.Then I executed "(gdb)n" command,the debug
toolbar icons became grey and i can not continue debugging my
application.I tried to debug another application and it showed none
output during the debugging. However, everything works like a charm in
emacs 23.4 on windows7 with
mingw32(emacs 24.1 on ubuntu 12.04 is also works very well).That'all, thank
you.


In GNU Emacs 24.1.1 (i386-mingw-nt6.1.7601)
 of 2012-06-10 on MARVIN
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --with-gcc (4.6) --cflags
 -ID:/devel/emacs/libs/libXpm-3.5.8/include
 -ID:/devel/emacs/libs/libXpm-3.5.8/src
 -ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include
 -ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include
 -ID:/devel/emacs/libs/giflib-4.1.4-1/include
 -ID:/devel/emacs/libs/jpeg-6b-4/include
 -ID:/devel/emacs/libs/tiff-3.8.2-1/include
 -ID:/devel/emacs/libs/gnutls-3.0.9/include'

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: CHS
  value of $XMODIFIERS: nil
  locale-coding-system: cp936
  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
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<help-echo> <help-echo> <help-echo> <help-echo> <drag-n-drop>
<help-echo> <escape> x g d b <return> <return> b SPC
1 8 <return> r <return> q <return> <help-echo> <escape>
x r e p <tab> <down-mouse-1> <mouse-2>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Target doesn't support non-stop mode.  Turning it off.
Switched to thread 1
Making completion list...
call-interactively: End of buffer [2 times]

Load-path shadows:
None found.

Features:
(shadow sort 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 mail-utils help-mode view
gdb-mi bindat json gud easy-mmode 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 browse-url url-util url-parse auth-source
eieio byte-opt bytecomp byte-compile cconv macroexp assoc gnus-util
password-cache url-vars mm-util mail-prsvr time-date china-util tooltip
ediff-hook vc-hooks lisp-float-type mwheel dos-w32 disp-table ls-lisp
w32-win w32-vars 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 multi-tty emacs)

[-- Attachment #2: Type: text/html, Size: 5150 bytes --]

bug#12163: 24.1; Can not input anything or showing none output when debugging c/c++ application.

[Eli Zaretskii]

[Please keep the bug address in the CC list.]

> From: qq510371827 <qq510371827@gmail.com>
> Date: Fri, 10 Aug 2012 10:58:11 +0800
> 
> Thanks for your help.But it doesn't work yet. I added :
>   setbuf(stdin,NULL);
>   setbuf(stdout,NULL);
> or,
>   setvbuf(stdin,NULL,_IONBF,0);
>   setvbuf(stdout,NULL,_IONBF,0);
> and
> fflush(stdout) after printf,
> All of the above didn't work, None output when debugging my application.In
> addition,I can not input values during debugging yet. for instance,
> 1...........scanf("%c",s);
> 2...........
> 3...........
> 4...........i=0; // set breakpoint at this line
> During the debugging,*What is the expected result?*
> It should suspend and wait IO buffer's input values. Then after I input a
> value in IO buffer and press RET it resumed and stopped at line 4 ( it hit
> the breakpoint).
> *But in fact What happens instead?*
> It run and directly stopped at line 4 and didn't give me a chance to input
> anything. I still input some values in io buffer and press RET but it
> didn't give me a response. It seems as if the debugger didn't recognize
> emacs' input/ouput IO buffer to be its input/output pipe and still kept
> waitting for input.
> This problem only appeared in emacs 24.1. Emacs 23.4 works very well
> without this problem.

Try invoking GDB from Emacs like this:

  M-x gud-gdb RET

If that doesn't help, either, then I'm clueless, sorry.  Perhaps
someone else could help.

bug#12163: 24.1; Can not input anything or showing none output when debugging c/c++ application.

[qq510371827]

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

2012/8/10 Eli Zaretskii <eliz@gnu.org>

> [Please keep the bug address in the CC list.]
> Sorry,it's my first time to file a bug report here. I will do as what you
> said.
> > From: qq510371827 <qq510371827@gmail.com>
> > Date: Fri, 10 Aug 2012 10:58:11 +0800
> >
> > Thanks for your help.But it doesn't work yet. I added :
> >   setbuf(stdin,NULL);
> >   setbuf(stdout,NULL);
> > or,
>
>   setvbuf(stdin,NULL,_IONBF,0);
> >   setvbuf(stdout,NULL,_IONBF,0);
> > and
> > fflush(stdout) after printf,
> > All of the above didn't work, None output when debugging my
> application.In
> > addition,I can not input values during debugging yet. for instance,
> > 1...........scanf("%c",s);
> > 2...........
> > 3...........
> > 4...........i=0; // set breakpoint at this line
> > During the debugging,*What is the expected result?*
> > It should suspend and wait IO buffer's input values. Then after I input a
> > value in IO buffer and press RET it resumed and stopped at line 4 ( it
> hit
> > the breakpoint).
> > *But in fact What happens instead?*
> > It run and directly stopped at line 4 and didn't give me a chance to
> input
> > anything. I still input some values in io buffer and press RET but it
> > didn't give me a response. It seems as if the debugger didn't recognize
> > emacs' input/ouput IO buffer to be its input/output pipe and still kept
> > waitting for input.
> > This problem only appeared in emacs 24.1. Emacs 23.4 works very well
> > without this problem.
>
> Try invoking GDB from Emacs like this:
>
>   M-x gud-gdb RET
>
> If that doesn't help, either, then I'm clueless, sorry.  Perhaps
> someone else could help.
>
 Thanks for your patience. It finally works. However, two other new
problem appeared after using 'gud-gdb'.
1).the code, gdb information and out/input datas mixed together in the same
buffer and 'gdb-many-windows' command didn't work any more.
2) You can refer this link:
 http://stackoverflow.com/questions/9676135/gud-gdb-emacs-24-not-working
The same problem as mine.

[-- Attachment #2: Type: text/html, Size: 3129 bytes --]

bug#12163: 24.1; Can not input anything or showing none output when debugging c/c++ application.

[Eli Zaretskii]

> From: qq510371827 <qq510371827@gmail.com>
> Date: Fri, 10 Aug 2012 17:14:14 +0800
> 
> > Try invoking GDB from Emacs like this:
> >
> >   M-x gud-gdb RET
> >
> > If that doesn't help, either, then I'm clueless, sorry.  Perhaps
> > someone else could help.
> >
>  Thanks for your patience. It finally works. However, two other new
> problem appeared after using 'gud-gdb'.
> 1).the code, gdb information and out/input datas mixed together in the same
> buffer and 'gdb-many-windows' command didn't work any more.

This is expected.  gud-gdb uses the old interface with GDB, which
doesn't support gdb-many-windows.

> 2) You can refer this link:
>  http://stackoverflow.com/questions/9676135/gud-gdb-emacs-24-not-working
> The same problem as mine.

No, it isn't the same.  Your problem was with getting input and output
to and from the debuggee.  The above URL describes a much more serious
problem, whereby Emacs doesn't show the source code of functions you
step through.  I don't see any of this in your original bug report
(and it surely works for me on MS-Windows).

As for the original problem: could you please post here a minimal C
program that exhibits the problem with I/O when you use "M-x gdb"?  I
will then try to look into the reasons of this and the possible ways
to solve that, when I have time.

Thanks.

bug#12163: 24.1; Can not input anything or showing none output when debugging c/c++ application.

[qq510371827]

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

2012/8/10 Eli Zaretskii <eliz@gnu.org>

> > From: qq510371827 <qq510371827@gmail.com>
> > Date: Fri, 10 Aug 2012 17:14:14 +0800
> >
> > > Try invoking GDB from Emacs like this:
> > >
> > >   M-x gud-gdb RET
> > >
> > > If that doesn't help, either, then I'm clueless, sorry.  Perhaps
> > > someone else could help.
> > >
> >  Thanks for your patience. It finally works. However, two other new
> > problem appeared after using 'gud-gdb'.
> > 1).the code, gdb information and out/input datas mixed together in the
> same
> > buffer and 'gdb-many-windows' command didn't work any more.
>
> This is expected.  gud-gdb uses the old interface with GDB, which
> doesn't support gdb-many-windows.
>
> > 2) You can refer this link:
> >  http://stackoverflow.com/questions/9676135/gud-gdb-emacs-24-not-working
> > The same problem as mine.
>
> No, it isn't the same.  Your problem was with getting input and output
> to and from the debuggee.  The above URL describes a much more serious
> problem, whereby Emacs doesn't show the source code of functions you
> step through.  I don't see any of this in your original bug report
> (and it surely works for me on MS-Windows).
> I'm sorry.I got it wrong.
> As for the original problem: could you please post here a minimal C
> program that exhibits the problem with I/O when you use "M-x gdb"?  I
> will then try to look into the reasons of this and the possible ways
> to solve that, when I have time.
>
> Thanks.
>
Ok,source code is as follows:
#include "stdio.h"
#include "ctype.h"
#include "string.h"

void Reverse(char* p,int n)
{
    if(--n > 0) Reverse(p+1,n);
    printf("%c",*p);
    fflush(stdout);
}
int main()
{
  //setbuf(stdin,NULL);
  //setbuf(stdout,NULL);
  // setvbuf(stdin,NULL,_IONBF,0);
  // setvbuf(stdout,NULL,_IONBF,0);
  //freopen("input.txt","r",stdin);
    char s[255],*p,*q;
    int i=0,n;
    fgets(s,255,stdin);
    s[strlen(s)-1] = ' ';
    p = q = s;                               //  set breakpoint at this
line.
    while(*p != '\0')
    {
        i++;
        p++;
        if(isspace(*p))
        {
            n = i;
            i = 0;
            Reverse(q,n);
            q = p+1;
        }
    }
    n = i;
    Reverse(q,n);
    printf("\n");
    return 0;
}
Thanks in advance.

[-- Attachment #2: Type: text/html, Size: 4808 bytes --]

bug#12163: 24.1; Can not input anything or showing none output when debugging c/c++ application.

[Eli Zaretskii]

> From: qq510371827 <qq510371827@gmail.com>
> Date: Fri, 10 Aug 2012 18:18:44 +0800
> 
> Ok,source code is as follows:
> #include "stdio.h"
> #include "ctype.h"
> #include "string.h"
> 
> void Reverse(char* p,int n)
> {
>     if(--n > 0) Reverse(p+1,n);
>     printf("%c",*p);
>     fflush(stdout);
> }
> int main()
> {
>   //setbuf(stdin,NULL);
>   //setbuf(stdout,NULL);
>   // setvbuf(stdin,NULL,_IONBF,0);
>   // setvbuf(stdout,NULL,_IONBF,0);
>   //freopen("input.txt","r",stdin);
>     char s[255],*p,*q;
>     int i=0,n;
>     fgets(s,255,stdin);
>     s[strlen(s)-1] = ' ';
>     p = q = s;                               //  set breakpoint at this line.
>     while(*p != '\0')
>     {
>         i++;
>         p++;
>         if(isspace(*p))
>         {
>             n = i;
>             i = 0;
>             Reverse(q,n);
>             q = p+1;
>         }
>     }
>     n = i;
>     Reverse(q,n);
>     printf("\n");
>     return 0;
> }
> Thanks in advance.

I looked into this.  The problem seems to be that gdb-mi.el is
confused wrt which text typed by the user to send to GDB and which to
the program being debugged.

Here's the session on Windows:

  Reading symbols from d:/usr/eli/data/rev.exe...done.
  (gdb) break 22
  Breakpoint 1 at 0x4013ae: file rev.c, line 22.
  (gdb) start
  Temporary breakpoint 2 at 0x40136f: file rev.c, line 19.
  Starting program: d:/usr/eli/data/rev.exe 
  [New Thread 2120.0x165c]

  Temporary breakpoint 2, main () at rev.c:19
  19	    int i=0,n;

At this point, I see the source in another window with the arrow at
line 19 and the breakpoint I set at line 22.

Now:

  (gdb) continue
  Continuing.

  Breakpoint 1, main () at rev.c:22
  22	    p = q = s;			//  set breakpoint at this line.
  (gdb) print s
  $1 = "23-thread-info --thread 1 \000 ..."

That "23-thread-info --thread 1" thing is a command sent by gdb-mi.el
to GDB.  But since the debbuggee is reading stdin with fgets, the
command ends up in the buffer read by fgets.  Which explains why the
program doesn't stop when fgets is called: the call to fgets returns
immediately with the above command as its input.

I tried to work around this by commenting out the "-thread-info"
command sent here:

  (defun gdb-starting (_output-field)
    ;; CLI commands don't emit ^running at the moment so use gdb-running too.
    (setq gdb-inferior-status "running")
    (gdb-force-mode-line-update
     (propertize gdb-inferior-status 'face font-lock-type-face))
    (setq gdb-active-process t)
    (setq gud-running t)
    ;; GDB doesn't seem to respond to -thread-info before first stop or
    ;; thread exit (even in non-stop mode), so this is useless.
    ;; Behavior may change in the future.
    (gdb-emit-signal gdb-buf-publisher 'update-threads))  <<<<<<<<<<<<<

Then I do get a chance to type some text when the debuggee is stuck in
fgets.  But what winds up in the buffer read by fgets is

  -interpreter-exec console "TEXT"

where TEXT is what I typed.  Evidently, gdb-mi thinks that what I
typed is a GDB command, so it wraps it with -interpreter-exec.

The above was on MS-Windows.  On GNU/Linux, I see a slightly different
manifestation of what seems to be the same problem: there, I cannot
get the debuggee to continue after I type some text that is supposed
to be read by fgets.  Sounds like the input never gets to the
debuggee, or maybe the debuggee's stdin is not line-buffered for some
reason.  In any case, the call to fgets never returns.

So I no longer think this is a Windows-specific problem, and my
original assertion that it has to do with different buffering on
Windows seems to be incorrect.

Perhaps someone who knows more about GUD and comint in general could
chime in and find out what is wrong here.  Or at least explain what
should be done in gdb-mi to treat separately GDB commands and input to
the debuggee.  Evidently, the old gud-gdb way of running GDB did that
correctly.

bug#12163: 24.1; Can not input anything or showing none output when debugging c/c++ application.

[qq510371827]

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

Thanks for your good work. The problem I encountered on windows is just as
you have described.But on linux(i am running ubuntu 12.04 under virtualbox)
,it works for me.
Here is the session on linux:
Reading symbols from /home/darks/Reverse...done.
(gdb) b 22
Breakpoint 1 at 0x80485e4: file Reverse.c, line 22.
(gdb) start
Temporary breakpoint 2 at 0x8048586: file Reverse.c, line 12.
Starting program: /home/darks/Reverse

At this point, I see the source in another window with the black arrow at
line 12 and the red breakpoint at line 22.
then,

(gdb) cotinue
continuing.

At this point,Nothing changed in the source code window .The debuggee hung
and is waitting input. So i input some values in IO buffer window and press
RET,the gdb session shows:

(gdb)

Now, the arrow goes into line 22 and hits the breakpoint.
Then :

(gdb) continue
or doing this repeatly: (gdb) next
The debuggee works very well.it showed all of the output in the IO buffer
window and normally terminted at last. That's all, just for your
information only. Thanks.
2012/8/11 Eli Zaretskii <eliz@gnu.org>

> I looked into this.  The problem seems to be that gdb-mi.el is
> confused wrt which text typed by the user to send to GDB and which to
> the program being debugged.
>
> Here's the session on Windows:
>
>   Reading symbols from d:/usr/eli/data/rev.exe...done.
>   (gdb) break 22
>   Breakpoint 1 at 0x4013ae: file rev.c, line 22.
>   (gdb) start
>   Temporary breakpoint 2 at 0x40136f: file rev.c, line 19.
>   Starting program: d:/usr/eli/data/rev.exe
>   [New Thread 2120.0x165c]
>
>   Temporary breakpoint 2, main () at rev.c:19
>   19        int i=0,n;
>
> At this point, I see the source in another window with the arrow at
> line 19 and the breakpoint I set at line 22.
>
> Now:
>
>   (gdb) continue
>   Continuing.
>
>   Breakpoint 1, main () at rev.c:22
>   22        p = q = s;                  //  set breakpoint at this line.
>   (gdb) print s
>   $1 = "23-thread-info --thread 1 \000 ..."
>
> That "23-thread-info --thread 1" thing is a command sent by gdb-mi.el
> to GDB.  But since the debbuggee is reading stdin with fgets, the
> command ends up in the buffer read by fgets.  Which explains why the
> program doesn't stop when fgets is called: the call to fgets returns
> immediately with the above command as its input.
>
> I tried to work around this by commenting out the "-thread-info"
> command sent here:
>
>   (defun gdb-starting (_output-field)
>     ;; CLI commands don't emit ^running at the moment so use gdb-running
> too.
>     (setq gdb-inferior-status "running")
>     (gdb-force-mode-line-update
>      (propertize gdb-inferior-status 'face font-lock-type-face))
>     (setq gdb-active-process t)
>     (setq gud-running t)
>     ;; GDB doesn't seem to respond to -thread-info before first stop or
>     ;; thread exit (even in non-stop mode), so this is useless.
>     ;; Behavior may change in the future.
>     (gdb-emit-signal gdb-buf-publisher 'update-threads))  <<<<<<<<<<<<<
>
> Then I do get a chance to type some text when the debuggee is stuck in
> fgets.  But what winds up in the buffer read by fgets is
>
>   -interpreter-exec console "TEXT"
>
> where TEXT is what I typed.  Evidently, gdb-mi thinks that what I
> typed is a GDB command, so it wraps it with -interpreter-exec.
>
> The above was on MS-Windows.  On GNU/Linux, I see a slightly different
> manifestation of what seems to be the same problem: there, I cannot
> get the debuggee to continue after I type some text that is supposed
> to be read by fgets.  Sounds like the input never gets to the
> debuggee, or maybe the debuggee's stdin is not line-buffered for some
> reason.  In any case, the call to fgets never returns.
>
> So I no longer think this is a Windows-specific problem, and my
> original assertion that it has to do with different buffering on
> Windows seems to be incorrect.
>
> Perhaps someone who knows more about GUD and comint in general could
> chime in and find out what is wrong here.  Or at least explain what
> should be done in gdb-mi to treat separately GDB commands and input to
> the debuggee.  Evidently, the old gud-gdb way of running GDB did that
> correctly.
>

[-- Attachment #2: Type: text/html, Size: 5638 bytes --]

bug#12163: 24.1; Can not input anything or showing none output when debugging c/c++ application.

[Eli Zaretskii]

> From: qq510371827 <qq510371827@gmail.com>
> Date: Sat, 11 Aug 2012 20:32:56 +0800
> 
> Thanks for your good work. The problem I encountered on windows is just as
> you have described.But on linux(i am running ubuntu 12.04 under virtualbox)
> ,it works for me.

What version of Emacs do you have on Ubuntu, and what version of GDB?

bug#12180: Fwd: bug#12163: 24.1; Can not input anything or showing none output when debugging c/c++ application.

[qq510371827]

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

emacs 24.1.1(i686-pc-linux-gnu),GTK+ Version 2.24.10 of 2012-07-17 on
berkelium, modified by Debian
GNU gdb (ubuntu/Linaro 7.4-2012.04-0ubuntu2)
ubuntu 12.04 LTS.

2012/8/11 Eli Zaretskii <eliz@gnu.org>

> > From: qq510371827 <qq510371827@gmail.com>
> > Date: Sat, 11 Aug 2012 20:32:56 +0800
> >
> > Thanks for your good work. The problem I encountered on windows is just
> as
> > you have described.But on linux(i am running ubuntu 12.04 under
> virtualbox)
> > ,it works for me.
>
> What version of Emacs do you have on Ubuntu, and what version of GDB?
>

[-- Attachment #2: Type: text/html, Size: 985 bytes --]

bug#12180: bug#12163: 24.1; Can not input anything or showing none output when debugging c/c++ application.

[Eli Zaretskii]

> From: qq510371827 <qq510371827@gmail.com>
> Date: Sat, 11 Aug 2012 23:11:33 +0800
> 
> emacs 24.1.1(i686-pc-linux-gnu),GTK+ Version 2.24.10 of 2012-07-17 on
> berkelium, modified by Debian
> GNU gdb (ubuntu/Linaro 7.4-2012.04-0ubuntu2)
> ubuntu 12.04 LTS.

Did you try this in a GUI session or in a TTY?  If in a GUI session,
can you try in a TTY session ("emacs -Q -nw")?

bug#12180: bug#12163: 24.1; Can not input anything or showing none output when debugging c/c++ application.

[qq510371827]

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

Yes,I have tried that.Both GUI session and TTY session work very well.
2012/8/12 Eli Zaretskii <eliz@gnu.org>

> > From: qq510371827 <qq510371827@gmail.com>
> > Date: Sat, 11 Aug 2012 23:11:33 +0800
> >
> > emacs 24.1.1(i686-pc-linux-gnu),GTK+ Version 2.24.10 of 2012-07-17 on
> > berkelium, modified by Debian
> > GNU gdb (ubuntu/Linaro 7.4-2012.04-0ubuntu2)
> > ubuntu 12.04 LTS.
>
> Did you try this in a GUI session or in a TTY?  If in a GUI session,
> can you try in a TTY session ("emacs -Q -nw")?
>

[-- Attachment #2: Type: text/html, Size: 855 bytes --]

bug#12180: bug#12163: 24.1; Can not input anything or showing none output when debugging c/c++ application.

[Eli Zaretskii]

> From: qq510371827 <qq510371827@gmail.com>
> Date: Sun, 12 Aug 2012 09:32:14 +0800
> Cc: 12180@debbugs.gnu.org, bug-gnu-emacs@gnu.org
> 
> Yes,I have tried that.Both GUI session and TTY session work very well.

I guess it's a matter of timing, then: there's a certain race
condition between Emacs that crams commands into GDB and the debuggee
that reads from stdin.  If the latter comes after Emacs already sent
all the commands, then the program will work correctly.  But that's a
guess; I hope someone knowledgeable about GUD, comint, and gdb-mi will
chime in.  Nick? somebody?

Anyway, I found a work-around for this problem.  After entering GDB,
and before running your program, type this command at GDB prompt:

  (gdb) set new-console on

This will cause GDB to create a separate console window for the input
and output of your program, when you run it, and you can then
communicate with your program without mixing its I/O with that of GDB.
Just be sure to put a breakpoint at the 'exit' call or at the last
line of your 'main' function, if you want to look at the program
output.  If you don't do that, the console will be automatically
closed when your program exits.

bug#12180: bug#12163: 24.1; Can not input anything or showing none output when debugging c/c++ application.

[qq510371827]

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

' set new-console on ' command works for me. I have tried eclipse cdt  and
it also has the same problem as emacs 24.1 on windows with mingw.
Strangely, why emacs 23.4 just works?
2012/8/13 Eli Zaretskii <eliz@gnu.org>

> > From: qq510371827 <qq510371827@gmail.com>
> > Date: Sun, 12 Aug 2012 09:32:14 +0800
> > Cc: 12180@debbugs.gnu.org, bug-gnu-emacs@gnu.org
> >
> > Yes,I have tried that.Both GUI session and TTY session work very well.
>
> I guess it's a matter of timing, then: there's a certain race
> condition between Emacs that crams commands into GDB and the debuggee
> that reads from stdin.  If the latter comes after Emacs already sent
> all the commands, then the program will work correctly.  But that's a
> guess; I hope someone knowledgeable about GUD, comint, and gdb-mi will
> chime in.  Nick? somebody?
>
> Anyway, I found a work-around for this problem.  After entering GDB,
> and before running your program, type this command at GDB prompt:
>
>   (gdb) set new-console on
>
> This will cause GDB to create a separate console window for the input
> and output of your program, when you run it, and you can then
> communicate with your program without mixing its I/O with that of GDB.
> Just be sure to put a breakpoint at the 'exit' call or at the last
> line of your 'main' function, if you want to look at the program
> output.  If you don't do that, the console will be automatically
> closed when your program exits.
>

[-- Attachment #2: Type: text/html, Size: 1973 bytes --]

bug#12163: bug#12180: Fwd: bug#12163: 24.1; Can not input anything or showing none output when debugging c/c++ application.

[Lars Ingebrigtsen]

qq510371827 <qq510371827@gmail.com> writes:

> I am running emacs 24.1 on windows7 32bit with mginw32.When debugging my
> c/c++ application I can not give an iputting and can not see any
> output. For example:
>          ...          //  line 1
>          ...          //  line 2
>          fgets(s,255,stdin); //line 3
>          ...         // line 4
>          ...         //line 5
>          i = 0; // line 6          Breakpoint is at this line.

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

Are you still seeing this issue on more recent versions of
Emacs/Windows/Mingw?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#12180: Fwd: bug#12163: 24.1; Can not input anything or showing none output when debugging c/c++ application.

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Are you still seeing this issue on more recent versions of
> Emacs/Windows/Mingw?

More information was requested, but no response was given within a
month, so I'm closing this bug report.  If the problem still exists,
please respond to this email and we'll reopen the bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no