This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Unbuffer stdout and stderr on windows


> Date: Fri, 16 Aug 2013 15:13:49 +0100
> From: Pedro Alves <palves@redhat.com>
> CC: gdb-patches@sourceware.org, brobecker@adacore.com, yao@codesourcery.com
> 
> > Right now, the amount of such "broken"
> > outputs is usually very small, and the fact that GDB flushes its
> > stdout probably makes it negligibly small.  If we cause more of these
> > instances to happen, the probability of a failure in a given session
> > will go up.
> 
> Not sure what you mean by causing more instances to happen?

I mean by that having more smaller chunks of text come out of GDB's
end of the pipe.

> It seems to me the mixing is a direct consequence of buffering.
> With buffering of stdout and stderr, the runtime will push chunks
> of lines to both stdout and stderr when the internal buffers are full,
> with no regard to line endings.  IOW, if gdb does:
> 
>  "line1\nline2\n" -> stdout
>  "LINE3\nLINE4\n" -> stderr
> 
> then depending on when is the internal stdout and stderr
> buffers filled, the runtime may well flush it like:
> 
> "line1\nliNE3\nLINE4\nn", and then "e2\n"

Yes, but since we flush stdout, the above shouldn't happen.

> > Maybe we should dig deeper in the original problem as well, because I
> > still have only a very vague notion of why would GDB, which is a
> > single-threaded program, cause mixing when it flushes stdout
> > regularly.  What am I missing?
> 
> I think so too.  A paste of the mixed output would be good
> to start.

Agreed.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]