From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id kACaLYkm5mlKiSwAWB0awg (envelope-from ) for ; Mon, 20 Apr 2026 09:13:45 -0400 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.a=rsa-sha256 header.s=Intel header.b=jrZJedLM; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id A9ED81E067; Mon, 20 Apr 2026 09:13:45 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED, RCVD_IN_VALIDITY_RPBL_BLOCKED,RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [38.145.34.32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 032E61E067 for ; Mon, 20 Apr 2026 09:13:44 -0400 (EDT) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id A63E64B358A2 for ; Mon, 20 Apr 2026 13:13:42 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A63E64B358A2 Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=intel.com header.i=@intel.com header.a=rsa-sha256 header.s=Intel header.b=jrZJedLM Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.12]) by sourceware.org (Postfix) with ESMTPS id 913A24B35884 for ; Mon, 20 Apr 2026 13:13:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 913A24B35884 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=intel.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 913A24B35884 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=198.175.65.12 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1776690795; cv=none; b=IpWvm+hdJZJLV0pRbdJQoSLhjWGEnqn6WDsAbzCHJcGbJnh3+F9sWQqi/9E1lxiRcsngma1T2ciGhub0yyaH0Je2tJ9MXpBt1mkUFYxdCx+hB1i15RmEG0mi/fsesSdzyt8y8S2LnTYA06ZF6EYf5vSFZmjhBb0UQI3DS6ZfSMs= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1776690795; c=relaxed/simple; bh=PTEqMxi8eR8joyZEo16gto8ocUPqus3drzyniuQOg8M=; h=DKIM-Signature:From:To:Subject:Date:Message-Id:MIME-Version; b=CwuDwQKVjPt0KRMFAxu3Mqk9KHANP5L3wCjnCigXTc8B/jSCc/1tqkWD42nYCF/HHArsXYOx4krV1ymPOa96oWw6bxYwsqpbWd2OOX43y4EhZE/N3064NDJXu7U3TM8mdQfEuGa9Wc6SD+wmmeiVCCaTvJWJJfvRKZwCUERP08E= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 913A24B35884 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1776690796; x=1808226796; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=PTEqMxi8eR8joyZEo16gto8ocUPqus3drzyniuQOg8M=; b=jrZJedLMLxUGB7RKFupyubxZZP1JrvqouYAelbTNsPpU60ZrR1okPmO0 BUJ77AiAci/dfBOsdP8q7ipFh2nNuZS3+TrRsbBVmwoed7byHrJmCPVJ1 GhvfZUmM44ReLVuzgIKPnETBReEFK6Zs75vBfUoX6uLFea/iM61dxxYlj Jh0wZRSfrtjI+iozNNh/zjqEAAzwZNRneIqiJ9I5OmpYpJpkuhBBFmVmf Ns3QYt3RYS6L401YRTCJ+1t9JiwtT8yRYbgPnjS66tfLLiemLMw39qB45 ISwNjDUUpmgCNFb0ua10l4NtIU883giZPkB2KrjFoZDqA7ZFnc/EK9j/l w==; X-CSE-ConnectionGUID: 6AhyKnPPQyWl+KsxE4X7AQ== X-CSE-MsgGUID: xPUfWkjaRHa+uSxhzLa+yQ== X-IronPort-AV: E=McAfee;i="6800,10657,11762"; a="89071938" X-IronPort-AV: E=Sophos;i="6.23,189,1770624000"; d="scan'208";a="89071938" Received: from fmviesa003.fm.intel.com ([10.60.135.143]) by orvoesa104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Apr 2026 06:13:15 -0700 X-CSE-ConnectionGUID: utmTWrqUTieZziZkpoRFyg== X-CSE-MsgGUID: c9VuLg9RRcGejxtqZmsFSg== X-ExtLoop1: 1 Received: from mkolish-mobl.ger.corp.intel.com (HELO localhost) ([10.245.160.217]) by fmviesa003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Apr 2026 06:13:12 -0700 From: Abdul Basit Ijaz To: gdb-patches@sourceware.org Cc: tankut.baris.aktemur@intel.com, abdul.b.ijaz@intel.com Subject: [PATCH 1/1] gdb: use waitpid directly in wait_to_die_with_timeout Date: Mon, 20 Apr 2026 15:12:55 +0200 Message-Id: <20260420131255.3744-1-abdul.b.ijaz@intel.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 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 Suppose we have a gdbserver target connected to GDB via a serial pipe. Also suppose the inferior is a long- or infinitely-running process launched by gdbserver. E.g. like this: (gdb) target remote | gdbserver - infinite.out If we use the 'detach' command, there is a hang: (gdb) detach Detaching from program: target:/tmp/infinite.out, process 308481 Detaching from process 308481 Ending remote debugging. Ignoring packet error, continuing... [Inferior 1 (process 308481) detached] >>> HANG <<< This is a regression since commit "[gdb] Use gdb::waitpid more often", before which GDB was giving the prompt after a timeout. The reason is in wait_to_die_with_timeout GDB calls gdb::waitpid to wait for gdbserver with an interrupt timeout set by an alarm call. In gdb::waitpid, we call gdb::handle_eintr, which repeatedly makes the syscall if it's interrupted. In this case, however, we wouldn't want to repeat the waitpid if the timeout expired. Hence, go back to using waitpid directly, instead of gdb::waitpid, to restore the previous behavior. A regression-test is included. One may wonder why gdbserver does not terminate and the timeout expires. The reason is, 'detach' command makes gdbserver detach from the process as the debugger, which resumes the debuggee process. If that process was launched by gdbserver instead of having been attached and if the process runs indefinitely long, gdbserver also waits indefinitely. From gdbserver/server.cc: /* If we are attached, then we can exit. Otherwise, we need to hang around doing nothing, until the child is gone. */ join_inferior (pid); exit (0); This indefinite wait causes the timeout with EINTR in waitpid call at the GDB side inside wait_to_die_with_timeout. Co-authored-by: Tankut Baris Aktemur --- gdb/testsuite/gdb.server/server-pipe-hang.c | 33 +++++++++++++ gdb/testsuite/gdb.server/server-pipe-hang.exp | 49 +++++++++++++++++++ gdb/utils.c | 5 +- 3 files changed, 86 insertions(+), 1 deletion(-) create mode 100644 gdb/testsuite/gdb.server/server-pipe-hang.c create mode 100644 gdb/testsuite/gdb.server/server-pipe-hang.exp diff --git a/gdb/testsuite/gdb.server/server-pipe-hang.c b/gdb/testsuite/gdb.server/server-pipe-hang.c new file mode 100644 index 00000000000..c9e5bc4051d --- /dev/null +++ b/gdb/testsuite/gdb.server/server-pipe-hang.c @@ -0,0 +1,33 @@ +/* This testcase is part of GDB, the GNU debugger. + + Copyright 2026 Free Software Foundation, Inc. + + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 3 of the License, or + (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program. If not, see . */ + +/* This program is intended to be started for the target using pipe command + inside GDB and then it loops. */ + +#include + +int +main (void) +{ + /* Prevent an infinite run. */ + alarm (60); + + while (1) + sleep (5); + + return 0; +} diff --git a/gdb/testsuite/gdb.server/server-pipe-hang.exp b/gdb/testsuite/gdb.server/server-pipe-hang.exp new file mode 100644 index 00000000000..50815bfaefc --- /dev/null +++ b/gdb/testsuite/gdb.server/server-pipe-hang.exp @@ -0,0 +1,49 @@ +# Copyright 2026 Free Software Foundation, Inc. + +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 3 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program. If not, see . + +# This test relies on starting gdbserver using the pipe syntax. Afterwards +# it checks if "detach" command does not hang. + +# Test is aimed at starting with the native target only. +# We manually create a pipe connection to a gdbserver below. +require gdb_protocol_is_native + +load_lib gdbserver-support.exp + +standard_testfile + +require allow_gdbserver_tests + +set gdbserver [find_gdbserver] +if { $gdbserver == "" } { + unsupported "could not find gdbserver" + return +} + +if {[build_executable "failed to prepare" $testfile $srcfile debug]} { + return +} + +clean_restart + +gdb_test "target remote | ${::gdbserver} - ${::binfile}" ".*" \ + "start gdbserver using pipe syntax" + +# The 5 seconds alarm in wait_to_die_with_timeout should make us get +# the prompt. +save_vars timeout { + set timeout 30 + gdb_test "detach" ".*" "detached without hang" +} diff --git a/gdb/utils.c b/gdb/utils.c index f5f19301460..e37e37797dd 100644 --- a/gdb/utils.c +++ b/gdb/utils.c @@ -3478,7 +3478,10 @@ wait_to_die_with_timeout (pid_t pid, int *status, int timeout) alarm (timeout); #endif - waitpid_result = gdb::waitpid (pid, status, 0); + /* Do not use gdb::waitpid here. We want to interrupt the + syscall with SIGALRM above to prevent waiting forever, and if + that interrupt happens, we don't want to repeat. */ + waitpid_result = waitpid (pid, status, 0); #ifdef SIGALRM alarm (0); -- 2.34.1 Intel Deutschland GmbH Registered Address: Dornacher Strasse 1, 85622 Feldkirchen, Germany Tel: +49 89 991 430, www.intel.de Managing Directors: Harry Demas, Jeffrey Schneiderman, Yin Chong Sorrell Chairperson of the Supervisory Board: Nicole Lau Registered Seat: Munich Commercial Register: Amtsgericht Muenchen HRB 186928