From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id x2kPNB1qJmIWFgAAWB0awg (envelope-from ) for ; Mon, 07 Mar 2022 15:25:01 -0500 Received: by simark.ca (Postfix, from userid 112) id C44291F3CA; Mon, 7 Mar 2022 15:25:01 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-3.8 required=5.0 tests=BAYES_00,MAILING_LIST_MULTI, NICE_REPLY_A autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 5A2521EA69 for ; Mon, 7 Mar 2022 15:25:01 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id CE83E385841D for ; Mon, 7 Mar 2022 20:25:00 +0000 (GMT) Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 40213385841D for ; Mon, 7 Mar 2022 20:24:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 40213385841D Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca Received: from [172.16.0.95] (192-222-180-24.qc.cable.ebox.net [192.222.180.24]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id C38E21EA69; Mon, 7 Mar 2022 15:24:49 -0500 (EST) Message-ID: <308a1654-45a3-3886-0094-eff4300c15a8@simark.ca> Date: Mon, 7 Mar 2022 15:24:49 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: [PATCH 09/11] Ensure EXIT is last event, gdb/linux Content-Language: tl To: Pedro Alves , gdb-patches@sourceware.org References: <20220303144020.3601082-1-pedro@palves.net> <20220303144020.3601082-10-pedro@palves.net> From: Simon Marchi In-Reply-To: <20220303144020.3601082-10-pedro@palves.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" On 2022-03-03 09:40, Pedro Alves wrote: > This is problematic for infrun.c:stop_all_threads, which asks the > target to report all thread exit events to infrun. For example, in > stop_all_threads, core GDB counts 2 threads that needs to be stopped. > It then asks the target to stop those 2 threads (with > target_stop(ptid)), and waits for 2 events to come back from the > target. Unfortunately, when waiting for events, the linux-nat target, > due to the random event selecting mentioned above, reports the > whole-process EXIT event even though the other thread has exited and > its exit hasn't been reported yet. As a consequence, stop_all_threads > receives one event, but waits indefinitely for the second one to come. > Effectively, GDB hangs forever. I don't really understand how we end up waiting forever. Why does reporting the leader exit event first make it so we discard the event for the other thread? Other than that, it looks sensible to me to ensure we return events in this order. Simon