From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1502 invoked by alias); 16 Aug 2013 13:42:39 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 1491 invoked by uid 89); 16 Aug 2013 13:42:39 -0000 X-Spam-SWARE-Status: No, score=-4.1 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_NO,SPF_SOFTFAIL autolearn=no version=3.3.2 Received: from mtaout22.012.net.il (HELO mtaout22.012.net.il) (80.179.55.172) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Fri, 16 Aug 2013 13:42:38 +0000 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MRM00700M1VHC00@a-mtaout22.012.net.il> for gdb-patches@sourceware.org; Fri, 16 Aug 2013 16:42:11 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MRM00673M2BVPC0@a-mtaout22.012.net.il>; Fri, 16 Aug 2013 16:42:11 +0300 (IDT) Date: Fri, 16 Aug 2013 13:42:00 -0000 From: Eli Zaretskii Subject: Re: [PATCH] Unbuffer stdout and stderr on windows In-reply-to: <520E296C.8090906@redhat.com> To: Pedro Alves Cc: gdb-patches@sourceware.org, brobecker@adacore.com, yao@codesourcery.com Reply-to: Eli Zaretskii Message-id: <83siy9n44r.fsf@gnu.org> References: <51EE23F8.1070905@codesourcery.com> <83wqohw4ee.fsf@gnu.org> <20130729192559.GA5348@ednor.casa.cgf.cx> <83d2q1xiyv.fsf@gnu.org> <51F6C7B2.3020400@redhat.com> <20130731034045.GA5565@ednor.casa.cgf.cx> <20130812211105.GA11128@adacore.com> <8361v9piop.fsf@gnu.org> <20130815173618.GA6955@ednor.casa.cgf.cx> <83eh9uonlg.fsf@gnu.org> <20130815175940.GD6955@ednor.casa.cgf.cx> <520E1109.7000304@redhat.com> <83y581n5ag.fsf@gnu.org> <520E296C.8090906@redhat.com> X-SW-Source: 2013-08/txt/msg00428.txt.bz2 > Date: Fri, 16 Aug 2013 14:30:20 +0100 > From: Pedro Alves > CC: gdb-patches@sourceware.org, brobecker@adacore.com, yao@codesourcery.com > > So how is emacs starting GDB? Via a pipe, of course. How else could Emacs read what GDB outputs and interpret it? > If it is started in a pipe, then what is forcing flushing at line > ends so that emacs doesn't break? Emacs has a special machinery to decode EOLs correctly even if input ends in a CR, and the NL comes later. But this machinery is heuristics and it's fragile. 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. > IOW, the testsuite is not special, in that if emacs starts > GDB with io connected to pipes, then it should be having the > exact same issues the testsuite has. The test suite is special, AFAIU. The original problem was not with buffering, it was with mixing stdout and stderr that confused Expect. An Emacs (human) user will never be confused by any such mix, and I believe MI output makes the mix improbable. In any case, I heard no complaints about any such situations, nor did I ever see that myself. > We do have "gdb_flush (gdb_stdout)" calls sprinkled through the > tree. If that is what makes emacs+pipe work, then OK, we can remain > with stdout fully buffered, but then I'd say that the bug is that > there are places that miss gdb_flush calls. 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?