From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 56539 invoked by alias); 23 Jun 2015 12:19:46 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 56526 invoked by uid 89); 23 Jun 2015 12:19:45 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 23 Jun 2015 12:19:44 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 68957347A41; Tue, 23 Jun 2015 12:19:43 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t5NCJeV4029933; Tue, 23 Jun 2015 08:19:42 -0400 Message-ID: <55894EDC.4050404@redhat.com> Date: Tue, 23 Jun 2015 12:19:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Doug Evans CC: Eli Zaretskii , gdb Subject: Re: Inadvertently run inferior threads References: <83h9tq3zu3.fsf@gnu.org> <55043A63.6020103@redhat.com> <8361a339xd.fsf@gnu.org> <5504555C.804@redhat.com> <550458E0.10206@redhat.com> <83y4jrsgui.fsf@gnu.org> <83ioaus6pt.fsf@gnu.org> <557ED083.1060804@redhat.com> <83si9tngaj.fsf@gnu.org> <557EF27E.3030900@redhat.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-06/txt/msg00067.txt.bz2 On 06/23/2015 05:07 AM, Doug Evans wrote: > Maybe we could give up on trying to cover up the stopped/running state > of the thread and just let info threads report something closer to > what's actually going on? > An asterisk or some such accompanying the output of threads in > intermediate states may be a sufficient clue to the the user. I strongly disagree. Plus, frontends also don't want to be flooded with useless *running -> *stopped -> *running transitions. Hiding internal stops isn't the complicated part. It's the opposite that is causing problems. That is, the hiding that threads run at all when doing an infcall: (gdb) p malloc (0) &"p malloc (0)\n" ~"$1 = (void *) 0x602010\n" ^done (gdb) Note no *running/*stopped above. The next question should be: if you do "print sleep (10000)", then since the thread / threads was/were never marked running, does that mean that the user/frontend can end up issuing another execution command that corrupts the ongoing infcall? The answer is no, but just because infcalls are always synchronous, so there's no way to issue any command while an infcall is ongoing anyway. More about it here: https://sourceware.org/ml/gdb-patches/2014-05/msg00273.html But fixing this bug may require removing the infcall-specific (pretend-it-doesnt-run) suppressions, resulting in something like: (gdb) p malloc (0) *running,thread-id="all" &"p malloc (0)\n" ~"$1 = (void *) 0x602010\n" *stopped,frame={addr="0x000000000040071c",func="main",args=[{name="argc",value="1"}, (...) ,thread-id="1",stopped-threads="all",core="3" ^done (gdb) I'm playing with tests and potential solutions. Thanks, Pedro Alves