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 2B3F3385800A for ; Sat, 26 Nov 2022 20:29:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2B3F3385800A Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca Received: from [10.0.0.11] (unknown [217.28.27.60]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 28E6C1E112; Sat, 26 Nov 2022 15:29:02 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1669494542; bh=WgOt1EXD9xFzIc0wvHsVBraBQr+V/jm0WI14TtE/sIE=; h=Date:Subject:To:References:From:In-Reply-To:From; b=FjiBNzGyc5whua1AdDKwujCQuvIGuPg4LDEGDDm7Oow/FGKyvIZHP9abCSJSEOe5U vl7IbYJxNW+PcMoKC7DYJvgehgOlw2LFhvPIsm8DrpQS1MkX1zOrPRVvHN5SayOe3i Gw0438Ygp7U5Pfw53WeHzyrH6BuORq2pwAdLlHlM= Message-ID: Date: Sat, 26 Nov 2022 15:29:00 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: [PATCH] [gdb/server] Emit warning for SIGINT failure Content-Language: en-US To: Tom de Vries , gdb-patches@sourceware.org References: <20221109203258.26431-1-tdevries@suse.de> From: Simon Marchi In-Reply-To: <20221109203258.26431-1-tdevries@suse.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-11.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,NICE_REPLY_A,SPF_HELO_PASS,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/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 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? Simon