Re: [PATCH]: machine interface not flushing properly

[David Whedon]

initial message was here, FYI:
http://sources.redhat.com/ml/bug-gdb/2001-05/msg00037.html

Wed, Jun 13, 2001 at 04:57:27PM -0400 wrote:
> > Hi,
> > 
> > I think I found a buglet in the gdbmi interface.  I've been going back and 
> > forth
> > on this but I'm fairly convinced my little code is right.
> > 
> > It appears as though we're not getting raw_stdout flushed properly.  I have
> > observed this behavior with gdb 5.0 as well as current (updated yesterday) 
> > cvs.
> > The wierd thing is that it looks like gdbmi is intentianally not flushing 
> > the
> > way I think it should, which causes me to doubt myself.
> > 
> > Here is an example of bad behavior (the example program is included later 
> > in the
> > message):
> 
> 
> 
> David,
> 
> This bug has me puzzled for two reasons:
I took a deeper look into it, it confused me some too.

> 
>       o       I was sure, for MI we turned
>               buffering off.  (Perhaps it
>               was only input buffering)

Yes, mi_console_file_new() creates a ui_file that will flush on a newline, but
stdio_fileopen() creates one that will not, at least when it is writing to a
pipe rather than a terminal (see mi-main.c:mi_command_loop() where these are
created)

> 
>       o       I was sure that a ``\n''
>               would force a flush anyway.

Are you refering to mi_console_file_fputs() in mi-console.c?  That funciton
checks for '\n' and flushes if it sees it.  However, raw_stdout doesn't use that
function for fputs, but rather uses stdio_file_fputs() in ui-file.c where a
newline doesn't cause a flush, just a simple fputs().

The odd thing here is that the bug example program I initially sent is reading
from a pipe.  It appears as though a pipe is by default buffered, while the
terminal is not.  If we replace gdb with foo.c:

$ more foo.c
#include <stdio.h>
#include <unistd.h>
int
main ()
{
  fputs ("(gdb) \n", stdout);
  sleep (10);
  return 0;
}
$
And then change GDB_PATH (in the initial bug example program), to point to foo.c
we get the bug:
$ grep "^#define" test.c
#define GDB_PATH "/home/davidw/foo"
$ gcc test.c -o test
$ ./test 
Error reading from gdb
We timeout out, that's a bug!
$ 

Hopefully that simplifies the question.  Maybe this isn't a bug, maybe I
shouldn't be using a pipe the way I am, but it still looks buggy to me.


-David