Community
Participate
Working Groups
Build Identifier: M20100909-0800 Stepping a line containing printf("!!!Hello World!!!") without a newline terminating the string, leaves the "Debug View" in the running state. Reproducible: Always
Code to demonstrate problem : #include <stdio.h> #include <stdlib.h> int main(void) { setvbuf(stdout, NULL, _IONBF, 0); // Stepping following line leaves debug view in run state. printf("!!!Hello World!!!"); return EXIT_SUCCESS; }
Created attachment 180875 [details] CDT 7.0.1 patch
When the program is run the following line is emitted to the Console View : !!!Hello World!!!23*stopped,reason="end-stepping-range",reason="breakpoint-hit",bkptno="1",thread-id="1",frame={addr="0x004011f1",func="main",args=[],file="../src/test.c",fullname="/cygdrive/d/user/cook/workspace_cdt_test/test/src/test.c",line="29"} The problem is caused by the users stdout being intermingled with the MI asynchronous message "23*stopped,reason....". The attached patch sub-parses the stdout line and allows RxThread.processMIOutput() to function correctly.
This seems to be a problem on Windows only, probably because we don't have a PTY. I'll have to test it from home where I have a Windows 7 machine.
I can see the problem on Windows. And it happens for CDI as well. The fix does not seem to work though. My line starts with: !!!Hello World!!!*stopped,reason=" The patter used in the patch is: "\\d+\\*stopped,reason=" But doesn't that look for digits at the beginning? Also, in some *stopped events, there is no 'reason' flag, so we should match for it.
Isn't this a GDB bug? This intermingling of program output breaks the gdb/mi output syntax.
(In reply to comment #6) > Isn't this a GDB bug? This intermingling of program output breaks the gdb/mi > output syntax. Definitely. But we can try to work around it.
I'm able to reproduce this bug on Linux when we don't use a PTY. It still happens with GDB 7.2. The problem is that this affects all MI output, not just the *stopped event. For example, in a multi-threaded program I got this: 263,335 [MI] 32-exec-continue --thread 1 263,338 [MI] 32^running 263,339 [MI] *running,thread-id="1" 263,339 [MI] (gdb) 263,345 [MI] !!!Hello World!!!=thread-created,id="2",group-id="i1" and the thread created event was lost to us. The problem is triggered by making the stream unbuffered: setvbuf(stdout, NULL, _IONBF, 0); I don't see how we can fix this ourselves. So, I think Toni was right and we can only say that it is a GDB bug. I will follow-up with GDB to get this fixed. If someone has an idea for a workaround, feel free to re-open.
I'm even wondering how we can fix this in GDB itself. My guess is that I will be told to use the "set inferior-tty" command to keep the output out of the MI streams. This is what we do for Linux. What is the reason we don't use a PTY for Windows? Is it that we didn't implement it in CDT?
I've been googling about this and I don't think this is a GDB bug, but more of a Windows limitation, as said here: http://dev.eclipse.org/mhonarc/lists/cdt-debug-dev/msg01985.html Dan refers to the command "set new-console on", which would make the output of the process come out in its own window. This feature has been discussed for DSF-GDB here: http://dev.eclipse.org/mhonarc/lists/cdt-dev/msg20345.html and within bug 231883, and was previously used for CDI (but no more). I'm thinking this is probably our best hope of avoiding the current bug. Note that bug 231883 comment 11 warns that we should make sure that using the new-console feature won't prevent us from interrupting the inferior. It is too late to try this for Indigo. However, you can make use of this already by adding the line set new-console on to a gdbinit file for your launch. In fact, with the new preference to set default gdbinit file, this becomes really easy (http://wiki.eclipse.org/CDT/User/NewIn80#New_set_of_preferences)
*** Bug 369720 has been marked as a duplicate of this bug. ***
*** Bug 384732 has been marked as a duplicate of this bug. ***
*** Bug 345029 has been marked as a duplicate of this bug. ***
