GNU bug report logs -
#12163
24.1; Can not input anything or showing none output when debugging c/c++ application.
Previous Next
Reported by: qq510371827 <qq510371827 <at> gmail.com>
Date: Thu, 9 Aug 2012 16:00:01 UTC
Severity: normal
Tags: moreinfo
Merged with 12180
Found in version 24.1
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 12163 in the body.
You can then email your comments to 12163 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#12163
; Package
emacs
.
(Thu, 09 Aug 2012 16:00:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
qq510371827 <qq510371827 <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Thu, 09 Aug 2012 16:00:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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)
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#12163
; Package
emacs
.
(Fri, 10 Aug 2012 06:46:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 12163 <at> debbugs.gnu.org (full text, mbox):
[Please keep the bug address in the CC list.]
> From: qq510371827 <qq510371827 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#12163
; Package
emacs
.
(Fri, 10 Aug 2012 09:24:01 GMT)
Full text and
rfc822 format available.
Message #11 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
2012/8/10 Eli Zaretskii <eliz <at> 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 <at> 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.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#12163
; Package
emacs
.
(Fri, 10 Aug 2012 09:59:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 12163 <at> debbugs.gnu.org (full text, mbox):
> From: qq510371827 <qq510371827 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#12163
; Package
emacs
.
(Fri, 10 Aug 2012 10:28:01 GMT)
Full text and
rfc822 format available.
Message #17 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
2012/8/10 Eli Zaretskii <eliz <at> gnu.org>
> > From: qq510371827 <qq510371827 <at> 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.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#12163
; Package
emacs
.
(Fri, 10 Aug 2012 18:06:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 12163 <at> debbugs.gnu.org (full text, mbox):
> From: qq510371827 <qq510371827 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#12163
; Package
emacs
.
(Sat, 11 Aug 2012 12:43:01 GMT)
Full text and
rfc822 format available.
Message #23 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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 <at> 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.
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#12163
; Package
emacs
.
(Sat, 11 Aug 2012 14:40:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 12163 <at> debbugs.gnu.org (full text, mbox):
> From: qq510371827 <qq510371827 <at> 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?
Merged 12163 12180.
Request was from
Glenn Morris <rgm <at> gnu.org>
to
control <at> debbugs.gnu.org
.
(Sat, 11 Aug 2012 17:52:02 GMT)
Full text and
rfc822 format available.
Added tag(s) fixed.
Request was from
Michael Albinus <michael.albinus <at> gmx.de>
to
control <at> debbugs.gnu.org
.
(Tue, 18 Dec 2012 13:43:01 GMT)
Full text and
rfc822 format available.
bug marked as fixed in version 24.4, send any further explanations to
12163 <at> debbugs.gnu.org and qq510371827 <qq510371827 <at> gmail.com>
Request was from
Michael Albinus <michael.albinus <at> gmx.de>
to
control <at> debbugs.gnu.org
.
(Tue, 18 Dec 2012 13:43:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#12163
; Package
emacs
.
(Tue, 18 Dec 2012 13:52:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 12163 <at> debbugs.gnu.org (full text, mbox):
reopen 12163
Sorry, the closure was accidental.
Best regards, Michael.
bug No longer marked as fixed in versions 24.4 and reopened.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Tue, 18 Dec 2012 13:52:02 GMT)
Full text and
rfc822 format available.
Added tag(s) patch.
Request was from
David Edmondson <dme <at> dme.org>
to
control <at> debbugs.gnu.org
.
(Tue, 18 Nov 2014 08:25:02 GMT)
Full text and
rfc822 format available.
Removed tag(s) patch.
Request was from
npostavs <at> users.sourceforge.net
to
control <at> debbugs.gnu.org
.
(Fri, 30 Jun 2017 04:15:01 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#12163
; Package
emacs
.
(Mon, 07 Feb 2022 00:06:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 12163 <at> debbugs.gnu.org (full text, mbox):
qq510371827 <qq510371827 <at> 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
Added tag(s) moreinfo.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Mon, 07 Feb 2022 00:06:03 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#12163
; Package
emacs
.
(Mon, 07 Mar 2022 02:38:02 GMT)
Full text and
rfc822 format available.
Message #49 received at 12163 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> 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
bug closed, send any further explanations to
12180 <at> debbugs.gnu.org and qq510371827 <qq510371827 <at> gmail.com>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Mon, 07 Mar 2022 02:38:03 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Mon, 04 Apr 2022 11:24:07 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 79 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.