From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.CeBiTec.Uni-Bielefeld.DE (smtp.CeBiTec.Uni-Bielefeld.DE [129.70.160.84]) by sourceware.org (Postfix) with ESMTPS id A9F733858413 for ; Thu, 13 Jul 2023 17:59:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A9F733858413 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=CeBiTec.Uni-Bielefeld.DE Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=cebitec.uni-bielefeld.de Received: from localhost (localhost [127.0.0.1]) by smtp.CeBiTec.Uni-Bielefeld.DE (Postfix) with ESMTP id 98A0FAF847; Thu, 13 Jul 2023 19:59:40 +0200 (CEST) X-Virus-Scanned: amavisd-new at CeBiTec.Uni-Bielefeld.DE Received: from smtp.CeBiTec.Uni-Bielefeld.DE ([127.0.0.1]) by localhost (smtp.cebitec.uni-bielefeld.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xso8ZjYTjgZb; Thu, 13 Jul 2023 19:59:39 +0200 (CEST) Received: from manam.CeBiTec.Uni-Bielefeld.DE (p50855614.dip0.t-ipconnect.de [80.133.86.20]) (Authenticated sender: ro) by smtp.CeBiTec.Uni-Bielefeld.DE (Postfix) with ESMTPSA id CD5D2AFBD2; Thu, 13 Jul 2023 19:59:39 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=CeBiTec.Uni-Bielefeld.DE; s=20200306; t=1689271179; bh=7zffkDvmjnG7V6L5nHJamXXWGU9Vfeb4VG9IdJvthdM=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=FnWNMcd32FsaUNuyWS5HsEjcSkJ4UZ2BElRuI6Uk0AjCaYCF8Sv8Ca+NKwyRdI5Fj F8umcR5SVX0MPhHOlP0/WZwjg8M7Af4KBAJxXIB5DSySi5GJayfHAAbsZx7+UeHudZ Qq0Myv7VCeUdWGqXuKdqN1z7+TYvBi7HfaTJtoOtV6XDlU/b/qzk/WlcIffNIMhHp+ 25HNrciSBNWwGo/OnRVzq7/NUK8eU2TXXHlgjHSbT4qGQf+jy5JjXg+aIp3cwWqRYT dX9Ki0x27kCqk9o4uCwiEYSEkvkfqrk3O8WJMzLwePbv9Tv6mtP4Q3jNTmnCaq7BkA EeGfR8vJHqOXw== From: Rainer Orth To: Tom Tromey Cc: gdb-patches@sourceware.org, Andrew Burgess Subject: Re: [PATCH] Guard against killing unrelated processes in amd64-disp-step.exp References: <87cz0vpy7g.fsf@tromey.com> Date: Thu, 13 Jul 2023 19:59:39 +0200 In-Reply-To: <87cz0vpy7g.fsf@tromey.com> (Tom Tromey's message of "Thu, 13 Jul 2023 10:34:27 -0600") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1.90 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-3786.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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: Hi Tom, >>>>>> "Rainer" == Rainer Orth writes: > > Rainer> When testing current gdb trunk on Solaris/amd64, the whole session was > Rainer> reliably terminated by make check. I could trace this to the following > Rainer> entry in gdb.arch/amd64-disp-step/gdb.log: > > Thank you for the patch. > > Rainer> If $inferior_pid doesn't refer a single process for some reason, this > Rainer> kill would terminate either a process group or the whole session. > > I don't mind the patch, it seems like an improvement -- but I wonder why That's what I thought: if for whatever reason the pid turns non-positive, hell breaks lose if that's passed to kill unchecked. > this ends up as -1, and whether a fix belongs elsewhere. gdb.log shows (gdb) PASS: gdb.arch/amd64-disp-step.exp: add into rcx: send_signal=off: verify_regs: rdi expected value jump test_rip_rcx Continuing at 0x4015b2. Program terminated with signal SIGALRM, Alarm clock. The program no longer exists. [...] [Current inferior is 1 [] (/vol/obj/gnu/gdb/gdb/11.4-amd64-dist/gdb/testsuite/outputs/gdb.arch/amd64-disp-step/amd64-disp-step)] lib/gdb.exp (get_inferior_pid) turns this into -1: proc get_inferior_pid {} { set pid -1 gdb_test_multiple "inferior" "get inferior pid" { -re "process (\[0-9\]*).*$::gdb_prompt $" { set pid $expect_out(1,string) pass $gdb_test_name } } return $pid } This is certainly something that shouldn't happen and fixing the underlying problem(s) would avoid the kill for sure. However, the Solaris gdb port is in a terrible state with about 3200 testsuite failures on amd64-pc-solaris2.11. I've made a few attempts to fix the most glaring issues, but that never got me anywere until I've decided that the gdb codebase is simply beyond my abilities. Rainer -- ----------------------------------------------------------------------------- Rainer Orth, Center for Biotechnology, Bielefeld University