From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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-Spam-Status: No, score=-3639.4 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, NICE_REPLY_A, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org 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: , X-List-Received-Date: Mon, 07 Mar 2022 20:24:51 -0000 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