From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4315 invoked by alias); 15 Jun 2015 19:07:13 -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 3489 invoked by uid 89); 15 Jun 2015 19:07:13 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_50,RCVD_IN_DNSWL_NONE,SPF_SOFTFAIL autolearn=no version=3.3.2 X-HELO: mtaout28.012.net.il Received: from mtaout28.012.net.il (HELO mtaout28.012.net.il) (80.179.55.184) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 15 Jun 2015 19:07:12 +0000 Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il (HyperSendmail v2007.08) id <0NQ000L00292FI00@mtaout28.012.net.il> for gdb@sourceware.org; Mon, 15 Jun 2015 22:06:33 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout28.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NQ000CDV2EX9990@mtaout28.012.net.il>; Mon, 15 Jun 2015 22:06:33 +0300 (IDT) Date: Mon, 15 Jun 2015 19:07:00 -0000 From: Eli Zaretskii Subject: Re: Inadvertently run inferior threads In-reply-to: <557F11CE.907@redhat.com> To: Pedro Alves Cc: gdb@sourceware.org Reply-to: Eli Zaretskii Message-id: <83a8w0okop.fsf@gnu.org> 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> <557ECCA5.7050506@redhat.com> <83vbepngxm.fsf@gnu.org> <557EEF0E.1040400@redhat.com> <83ioaoopkh.fsf@gnu.org> <557F11CE.907@redhat.com> X-IsSubscribed: yes X-SW-Source: 2015-06/txt/msg00034.txt.bz2 > Date: Mon, 15 Jun 2015 18:56:30 +0100 > From: Pedro Alves > CC: gdb@sourceware.org > > On 06/15/2015 06:21 PM, Eli Zaretskii wrote: > >> Date: Mon, 15 Jun 2015 16:28:14 +0100 > >> From: Pedro Alves > >> CC: gdb@sourceware.org > >> > >>>> So that should mean that even for GNU/Linux, it should be possible > >>>> to end in the exact same, when any thread other than the one that we > >>>> had started the infcall in reports an event that doesn't cause a stop. > >>>> E.g., a thread specific breakpoint, a "handle nostop" signal, etc. > >>> > >>> Does that involve minus_one_ptid on GNU/Linux as well? If not, that > >>> call will not mark all threads as running, will it? > >> > >> It does. user_visible_resume_ptid returns the same irrespective > >> of target_can_async. > > > > Then how come your test program ended up showing just that additional > > thread running? You even said you couldn't explain why I saw all my > > threads running on Windows. > > Because linux-nat.c does not report any event to infrun when a > thread is created, it just immediately goes back to waiting, unlike > windows-nat.c, which reports TARGET_WAITKIND_SPURIOUS. By previous > test program did not have the new thread trip on any event after > its creation. Then perhaps the right solution is not to call discard_cleanups at that point under any condition, always call do_cleanups. After all, all the threads are stopped at that point, so why not register that?