Description jamesahart79 2011-05-06 16:32:42 EDT

Build Identifier: 20110218-0911

On windows machines, the console which runs the actual debugger (gdb/mi) also displays any console output from the target code (e.g. printf statements in C).  This makes sense, but it appears that the parser in Eclipce/CDT is incapable of handling the occasional interference that can occur between these two outputs.  In particular, if by some chance the output from gdb/mi does not have a newline, then the output from the debugger will not be parsed by Eclipse as such, resulting in many nasty side effects, such as the program freezing if it hits a breakpoint at the wrong time (e.g. the debugger knows that a breakpoint has been hit and is waiting to continue, while Eclipse does *not* realize that a breakpoint has been hit, and thus allows no way to continue.)

In addition, it appears that the stdout from the code is not synchronous with the output from the debugger, as per bug 336041.  In my case, this asynchronicity actually causes the interference between dgb/mi and the console output; without the asynchronicity, there is no interference.

In my case, this results in freezing if I create a C project which consists exclusively of the code:

 #include <stdio.h>

int main(  ) {
	int i;
	printf( "Help\n" );

	for ( i=0; i<5000; i++ ) {
		printf( "Number: %i %i\n", 5*i, i*i );
	}
	printf("Test breakpoint error!\n");
	return 0;
}

This program (quite naturally) does not occur in gdb alone because humans don't have trouble parsing interference between text streams.  I assume it is an interaction between gdb/mi and Eclipse.  Also, I could find no evidence of bug 336041 in gdb.

Reproducible: Always

Steps to Reproduce:
1.Create a new C project.
2.Create a new C file.
3.Enter the above program.
4.Place a breakpoint at line containing the printf immediately after the for loop.
5.Start a debug run.

It happens every time on my machine at the same place in the output, but may depend on the environment.