From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15992 invoked by alias); 16 Aug 2013 14:13:58 -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 15983 invoked by uid 89); 16 Aug 2013 14:13:57 -0000 X-Spam-SWARE-Status: No, score=-8.6 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Fri, 16 Aug 2013 14:13:56 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r7GEDqko006757 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 16 Aug 2013 10:13:52 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r7GEDoSs005315; Fri, 16 Aug 2013 10:13:50 -0400 Message-ID: <520E339D.3020209@redhat.com> Date: Fri, 16 Aug 2013 14:13:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Eli Zaretskii CC: gdb-patches@sourceware.org, brobecker@adacore.com, yao@codesourcery.com Subject: Re: [PATCH] Unbuffer stdout and stderr on windows 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> <83siy9n44r.fsf@gnu.org> In-Reply-To: <83siy9n44r.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-08/txt/msg00431.txt.bz2 On 08/16/2013 02:42 PM, Eli Zaretskii wrote: >> 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? Dunno, perhaps some hidden console magic. >> 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. That sounds like the opposite scenario. That is, GDB sending "\r\n", and emacs getting "\r" first, putting it in an internal line buffer, and then waiting for "\n" for the line to be complete. That's doing based line based input reading when the lower level routines don't do it for you. I don't see how to get around this if you have either non-buffered or fully buffered output as in both cases, you have reads returning data around characters that are not line endings. > 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? > >> 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. 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" If it's not this, but whole lines being swapped somehow, maybe always flushing stdout before outputting stderr and vice versa is likely to fix it, I'd guess? Even if the swapping is completely whole-line based somehow, I still think that the testsuite is not special. Just because emacs doesn't _care_ that the output might be swapped, it's still a fact that it is, and the testsuite exercises what consumers of GDB output see. > 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? I think so too. A paste of the mixed output would be good to start. -- Pedro Alves