[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#12163: 24.1; Can not input anything or showing none output when debu

From: qq510371827
Subject: bug#12163: 24.1; Can not input anything or showing none output when debugging c/c++ application.
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.
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. 

(gdb) cotinue

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:


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 <address@hidden>
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.


  (gdb) continue

  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")
     (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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]