From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4288 invoked by alias); 6 Oct 2008 13:49:46 -0000 Received: (qmail 4274 invoked by uid 22791); 6 Oct 2008 13:49:45 -0000 X-Spam-Check-By: sourceware.org Received: from imr1.ericy.com (HELO imr1.ericy.com) (198.24.6.9) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 06 Oct 2008 13:49:03 +0000 Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id m96Dnaif001024; Mon, 6 Oct 2008 08:49:36 -0500 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Oct 2008 08:48:59 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Flush ^running Date: Mon, 06 Oct 2008 13:49:00 -0000 Message-ID: <6D19CA8D71C89C43A057926FE0D4ADAA063DBBDF@ecamlmw720.eamcs.ericsson.se> In-Reply-To: <200810041901.40210.vladimir@codesourcery.com> References: <200810041901.40210.vladimir@codesourcery.com> From: "Marc Khouzam" To: "Vladimir Prus" , 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: 2008-10/txt/msg00147.txt.bz2 Hi, I've also run into that problem. When continuing or stepping over a sleep(), I would only see the ^running and *running after the sleep() call had finished. Just like you , it only happened when using the frontend, although is happened with CLI commands from the frontend (continue, next). Your patch fixes this issue. One less thing to worry about. Thanks! Marc > -----Original Message----- > From: gdb-patches-owner@sourceware.org=20 > [mailto:gdb-patches-owner@sourceware.org] On Behalf Of Vladimir Prus > Sent: Saturday, October 04, 2008 11:02 AM > To: gdb-patches@sources.redhat.com > Subject: Flush ^running >=20 >=20 > I've run into a case where gdb would not print ^running in response > to -exec-continue -- at least not during the time frontend is willing > to wait for the response. The problem only happened for my when gdb > is driven by a frontend, not on command line; I don't know=20 > what frontend > does differently. I've checked in the below patch to fix this. >=20 > - Volodya >=20 >=20