From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: qq510371827 Newsgroups: gmane.emacs.bugs 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 Message-ID: References: <83obmkdoli.fsf@gnu.org> <83ehnfdzgw.fsf@gnu.org> <837gt7dqjm.fsf@gnu.org> <83628qeikl.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=20cf302078886e18ea04c6fcabbe X-Trace: dough.gmane.org 1344688495 11807 80.91.229.3 (11 Aug 2012 12:34:55 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 11 Aug 2012 12:34:55 +0000 (UTC) To: 12163@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Aug 11 14:34:54 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1T0Au2-0000G0-EQ for geb-bug-gnu-emacs@m.gmane.org; Sat, 11 Aug 2012 14:34:50 +0200 Original-Received: from localhost ([::1]:53246 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T0Au1-0005ol-LJ for geb-bug-gnu-emacs@m.gmane.org; Sat, 11 Aug 2012 08:34:49 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:36084) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T0Atw-0005mk-Iu for bug-gnu-emacs@gnu.org; Sat, 11 Aug 2012 08:34:47 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T0Att-0004iZ-D3 for bug-gnu-emacs@gnu.org; Sat, 11 Aug 2012 08:34:44 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:38786) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T0Att-0004iV-9O for bug-gnu-emacs@gnu.org; Sat, 11 Aug 2012 08:34:41 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1T0B1x-0006U4-Ok for bug-gnu-emacs@gnu.org; Sat, 11 Aug 2012 08:43:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: qq510371827 Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 11 Aug 2012 12:43:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 12163 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.134468893024864 (code B ref -1); Sat, 11 Aug 2012 12:43:01 +0000 Original-Received: (at submit) by debbugs.gnu.org; 11 Aug 2012 12:42:10 +0000 Original-Received: from localhost ([127.0.0.1]:48332 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T0B17-0006Sy-5N for submit@debbugs.gnu.org; Sat, 11 Aug 2012 08:42:09 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:54814) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T0B13-0006So-Fl for submit@debbugs.gnu.org; Sat, 11 Aug 2012 08:42:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T0Asw-0004dj-JQ for submit@debbugs.gnu.org; Sat, 11 Aug 2012 08:33:44 -0400 Original-Received: from lists.gnu.org ([208.118.235.17]:33213) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T0Asw-0004de-Fn for submit@debbugs.gnu.org; Sat, 11 Aug 2012 08:33:42 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:35927) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T0Asu-0004zP-NV for bug-gnu-emacs@gnu.org; Sat, 11 Aug 2012 08:33:42 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T0Ass-0004d7-Px for bug-gnu-emacs@gnu.org; Sat, 11 Aug 2012 08:33:40 -0400 Original-Received: from mail-wi0-f169.google.com ([209.85.212.169]:57531) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T0Ass-0004cy-EP for bug-gnu-emacs@gnu.org; Sat, 11 Aug 2012 08:33:38 -0400 Original-Received: by wibhm2 with SMTP id hm2so1757979wib.0 for ; Sat, 11 Aug 2012 05:33:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=68vFkueorY8iuUPws+pf8ytS1mSyTOFGmCx0v7/ydrU=; b=F3QRKhNTpv05Tzb4Pw3ORGULzEKZOw0hqaFrfhK6P+ssGKnPtwlM8UGeskqSBxURg7 d3ZJsNA0aoEWS5B4QciKDkW/ObPtz8QDAtp2zzxy55VJMDo6q1z860942fcMxoq8s+is SOUV/t9BzLHyznls19LK2VmgbJbnFcG74iS+EgW9x92sc0CM73njbJhmxzsny3g07AvW SHb3juqjlENROz6cyEOS5QcREFtxlOoGiEkxe5I85ABHnL0KcdvL+cVqsQ8tvHOdpDKW 39SsIDpJJ+E6GVnKmP3Vaj34V1MMvNHfne97UUcxayN0p4JgnZipEEcPp6ZWB19uckgS 4rnQ== Original-Received: by 10.217.3.7 with SMTP id q7mr3420840wes.47.1344688417019; Sat, 11 Aug 2012 05:33:37 -0700 (PDT) Original-Received: by 10.216.210.19 with HTTP; Sat, 11 Aug 2012 05:32:56 -0700 (PDT) In-Reply-To: <83628qeikl.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:63035 Archived-At: --20cf302078886e18ea04c6fcabbe Content-Type: text/plain; charset=ISO-8859-1 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 > 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. > --20cf302078886e18ea04c6fcabbe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 b= reakpoint at line 22.=A0
then,

(gdb= )=A0cotinue
continuing.

At this point,Nothing changed in the source=A0code window .The debuggee hun= g and is waitting input. So i input some values in IO buffer window and pre= ss RET,the gdb session shows:

(gdb)=A0

Now, the arrow goes into line 22 and hits the breakpoin= t.=A0
Then :

(gdb)=A0continue =A0
or doing this repeatly:=A0(gdb)= =A0next=A0
The debuggee works very well.it showed = all of the output in the IO buffer window and normally terminted at last. T= hat's all, just for your information only. Thanks.
2012/8/11 Eli Zaretskii <eliz@gnu.org>
I looked into this. =A0The 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:

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

=A0 Temporary breakpoint 2, main () at rev.c:19
=A0 19 =A0 =A0 =A0 =A0int i=3D0,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:

=A0 (gdb) continue
=A0 Continuing.

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

That "23-thread-info --thread 1" thing is a command sent by gdb-m= i.el
to GDB. =A0But since the debbuggee is reading stdin with fgets, the
command ends up in the buffer read by fgets. =A0Which 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"<= br> command sent here:

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

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

=A0 -interpreter-exec console "TEXT"

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

The above was on MS-Windows. =A0On 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. =A0Sounds like the input never gets to the
debuggee, or maybe the debuggee's stdin is not line-buffered for some reason. =A0In 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. =A0Or at least explain what
should be done in gdb-mi to treat separately GDB commands and input to
the debuggee. =A0Evidently, the old gud-gdb way of running GDB did that
correctly.

--20cf302078886e18ea04c6fcabbe--