From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7911 invoked by alias); 27 Jun 2012 16:54:40 -0000 Received: (qmail 7891 invoked by uid 22791); 27 Jun 2012 16:54:37 -0000 X-SWARE-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_NO,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from mtaout22.012.net.il (HELO mtaout22.012.net.il) (80.179.55.172) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 27 Jun 2012 16:54:21 +0000 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0M6A00200C8EON00@a-mtaout22.012.net.il> for gdb-patches@sourceware.org; Wed, 27 Jun 2012 19:53:25 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.210.75]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M6A0029OC90JN50@a-mtaout22.012.net.il>; Wed, 27 Jun 2012 19:53:24 +0300 (IDT) Date: Wed, 27 Jun 2012 16:54:00 -0000 From: Eli Zaretskii Subject: Re: [PATCH]Fix that GDB will get hang on Windows when using pipe to get stdout and stderr from stub In-reply-to: <000001cd5338$ded61b20$9c825160$%guo@arm.com> To: Terry Guo Cc: gdb-patches@sourceware.org, Joey.Ye@arm.com, Matthew.Gretton-Dann@arm.com, palves@redhat.com, daniel.jacobowitz@gmail.com Reply-to: Eli Zaretskii Message-id: <83hatw8zn1.fsf@gnu.org> References: <000001cd5338$ded61b20$9c825160$%guo@arm.com> X-IsSubscribed: yes 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 X-SW-Source: 2012-06/txt/msg00833.txt.bz2 > From: "Terry Guo" > Cc: , > "Joey Ye" , > "Matthew Gretton-Dann" , > "'Pedro Alves'" , > > Date: Tue, 26 Jun 2012 09:13:14 +0800 > > I noticed a cross-built MINGW arm-none-eabi GDB will get hang on Windows > when use pipe to get stderr and stdout from stub. The command used to start > stub in GDB is "target extended-remote | > stub-that-write-stderr-before-stdout". For my case, after send > "$vFlashDone#ea" to stub, GDB get hang. The GDB source show that GDB will > keep waiting for ACK message from stdout of stub, after send the packet. > Unfortunately my stub will write some kind of log information into stderr > and this action takes place before stub write ACK message to its stdout. So > the only pipe is occupied by stderr which is waiting for GDB to consume, > while GDB keep waiting for message from the stdout which hasn't pipe to use. > We finally end up with a deadlock on pipe between GDB/stderr/stdout. > > The following patch can avoid such deadlock by letting GDB also probe and > consume stderr when waiting for stdout. Please review and comment. I only read it superficially, but it looked fine to me. Thanks.