From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out1.suse.de (smtp-out1.suse.de [IPv6:2001:67c:2178:6::1c]) by sourceware.org (Postfix) with ESMTPS id 997413858C2C for ; Sun, 27 Nov 2022 09:27:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 997413858C2C Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id B537621B92; Sun, 27 Nov 2022 09:27:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1669541248; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=BswPrpvJEO1aX5ZicEqK9NAqcWdBJAPD2mCmBORBoyo=; b=IVedvTKHeXkcnucuou0DZhkmJZ9Qgz5dyJNdhuiKEbW/cFqDKfEHMsXVWvpjC+sFjCeLDB 0CQyIGr//A4sa4MDRZcLhPYBeD0SI8iNNXQS6sOvS4mVPjYezbdADaCSxtXDFoqBQwUHX6 gsURrz/OwwvSROdDGmXG758pmVJTwFQ= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1669541248; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=BswPrpvJEO1aX5ZicEqK9NAqcWdBJAPD2mCmBORBoyo=; b=8S7CUoxtIsRj5JGEI4ObstAF8OUIOvTeqSKepoCDArySCgqe8aaUX58IErveuI0Am/cZgF 15amBYVKVDgX0TDw== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 9963313428; Sun, 27 Nov 2022 09:27:28 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id eKyiI4Atg2OXUAAAMHmgww (envelope-from ); Sun, 27 Nov 2022 09:27:28 +0000 Message-ID: <0d3b98c3-ac42-1046-df0e-f6c02875784f@suse.de> Date: Sun, 27 Nov 2022 10:27:28 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Subject: Re: [PATCH] [gdb/server] Emit warning for SIGINT failure Content-Language: en-US To: Simon Marchi , gdb-patches@sourceware.org References: <20221109203258.26431-1-tdevries@suse.de> From: Tom de Vries In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-12.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 11/26/22 21:29, Simon Marchi wrote: > > > On 11/9/22 15:32, Tom de Vries via Gdb-patches wrote: >> Consider the executable from test-case gdb.base/interrupt-daemon.exp. >> >> When starting it using gdbserver: >> ... >> $ ./build/gdbserver/gdbserver localhost:2345 \ >> ./outputs/gdb.base/interrupt-daemon/interrupt-daemon >> ... >> and connecting to it using gdb: >> ... >> $ gdb -q -ex "target remote localhost:2345" \ >> -ex "set follow-fork-mode child" \ >> -ex "break daemon_main" -ex cont >> ... >> we are setup to do the same as in the test-case: interrupt a running inferior >> using ^C. >> >> So let's try: >> ... >> (gdb) continue >> Continuing. >> ^C >> ... >> After pressing ^C, nothing happens. This a known problem, filed as >> PR remote/18772. >> >> The problem is that in linux_process_target::request_interrupt, a kill is used >> to send a SIGINT, but it fails. And it fails silently. >> >> Make the failure verbose by adding a warning, such that the gdbserver output >> becomes more helpful: >> ... >> Process interrupt-daemon created; pid = 15068 >> Listening on port 2345 >> Remote debugging from host ::1, port 35148 >> Detaching from process 15068 >> Detaching from process 15085 >> gdbserver: Sending SIGINT to process group of pid 15068 failed: \ >> No such process >> ... >> >> Note that the failure can easily be reproduced using the test-case and target >> board native-gdbserver: >> ... >> (gdb) continue^M >> Continuing.^M >> PASS: gdb.base/interrupt-daemon.exp: fg: continue >> ^CFAIL: gdb.base/interrupt-daemon.exp: fg: ctrl-c stops process (timeout) >> ... >> as reported in PR server/23382. >> >> Tested on x86_64-linux. >> --- >> gdbserver/linux-low.cc | 5 ++++- >> 1 file changed, 4 insertions(+), 1 deletion(-) >> >> diff --git a/gdbserver/linux-low.cc b/gdbserver/linux-low.cc >> index 0cbfeb99086..f4df02d3ac9 100644 >> --- a/gdbserver/linux-low.cc >> +++ b/gdbserver/linux-low.cc >> @@ -5467,7 +5467,10 @@ linux_process_target::request_interrupt () >> { >> /* Send a SIGINT to the process group. This acts just like the user >> typed a ^C on the controlling terminal. */ >> - ::kill (-signal_pid, SIGINT); >> + int res = ::kill (-signal_pid, SIGINT); >> + if (res == -1) >> + warning (_("Sending SIGINT to process group of pid %ld failed: %s"), >> + signal_pid, safe_strerror (errno)); > > I don't fully understand the issue about the separate process group and > all that (and I just have a few minutes so I won't dig into that right > now), but I don't see any downside to your patch. Therefore: > > Approved-By: Simon Marchi > Thanks for the review, much appreciated. > On a tangential note, at first glance, this use of the signal_pid global > seems bogus. If you run two inferiors, signal_pid will have the pid of > the second one. Then, if you only resume the first one and press > ctrl-c, I guess we'll send a SIGINT to the second one, that is not > resumed, and then wait for it to report a stop, which won't happen? Agreed, and this warning won't trigger for that scenario, since the signal_pid will be valid. I don't understand at this point whether the correct pid is somewhere available in gdbserver or needs to be passed by gdb, but unfortunately I don't see an opportunity to look into this further before the upcoming gdb 13 release (and the fact that this has remained unfixed for 7 years suggests to me that it's not a trivial fix). Thanks, - Tom