From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id UUVEEtq+/GUI2RAAWB0awg (envelope-from ) for ; Thu, 21 Mar 2024 19:12:26 -0400 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=linaro.org header.i=@linaro.org header.a=rsa-sha256 header.s=google header.b=WONAGag0; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 372601E0C0; Thu, 21 Mar 2024 19:12:26 -0400 (EDT) Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (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 D34661E08C for ; Thu, 21 Mar 2024 19:12:23 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 4D6193858295 for ; Thu, 21 Mar 2024 23:12:23 +0000 (GMT) Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) by sourceware.org (Postfix) with ESMTPS id 34A233858D28 for ; Thu, 21 Mar 2024 23:11:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 34A233858D28 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 34A233858D28 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::630 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1711062716; cv=none; b=W2oMMe2a+mg0gXZoDl0ocPwh365ZhttylJv3GXdiXUjXK/Y5cMgfevGR8ZCT23JvfQftC197GVYRWP5zUjnla6XQIVxOZglQ5BUHCfUkdroaGlU2zTBgPj7dbqSbUUXYXh699S3rfOe2y6Xb+Zdx2DuSGYCDbnZLVSIn81Lb4a4= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1711062716; c=relaxed/simple; bh=WF/Cs6RnUsBu1252EntJme6DMTjKdQbTESGBxMsIZGU=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=CtSm4be9d6GaTWzzVJHKfvJDNcyHd6Usjc/s6cIuKbJuCpPYqAYA14qRc0v7dLk9sHQYPwUUIT1NQTYRCZ70w8+ruqD0tXmyDvZLS1kR3BoqpghZlBjjvxw2tYMP0D1MWMxwk/1FC4tJOJMiFKuzNr1NPp6BYElqb/E6GWaMIMA= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-pl1-x630.google.com with SMTP id d9443c01a7336-1def142ae7bso13668325ad.3 for ; Thu, 21 Mar 2024 16:11:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1711062713; x=1711667513; darn=sourceware.org; h=content-transfer-encoding:mime-version:message-id:date:subject:to :from:from:to:cc:subject:date:message-id:reply-to; bh=9F9O3nPoYUc/x8Xrxxvb92CXvgDqsaPA/kAzTlF62cQ=; b=WONAGag0hkfpt/wdNsiL76t9mCuR/p9UBOOaPPC5LvIt5QLsHmLrw00OsbvfcRvQrW 4ND+wuJSzBBsB3mAgrj4NvtiDTTDkd1TDmvW/QGtoDzsaDQniGaqfrTiZT23ulI8oq/x jRbQTpKh02YBHnWXWTrI6OgGk+911QklSSD4sVbiChADvivxbdLcVgxna1uhtxQjpjkz fKp2ZegxNv9vXSbtKCNhRpKXTPfMMlbTcVL6kQYeaA4rWvt48XN4owW4xN1hVZLNwFQW /FnrDPYOy7ANArrXo3oKJgRuyf6SSgk8D8LZCDcnVS7vwgiAJ3xaGSj5pBRukm7FpFMS ZR4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711062713; x=1711667513; h=content-transfer-encoding:mime-version:message-id:date:subject:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=9F9O3nPoYUc/x8Xrxxvb92CXvgDqsaPA/kAzTlF62cQ=; b=jQQQ4WNQ21aNjwKxQBVcDSaH6G3/0ixEruOVgMZ8Cv4X4UyFY0N4lkiCFM0+FV+1v+ 89JOXAAXs+iShsqONl7xFr+epTtPl3flK5WTSpWtgkLPuZYMDUJ+us6l5JWQhTIwd5m9 BRtX0DenI6u9B7wzR+Ku4BYZZG9rL49XZ52y1PlTReBdyKEex4ulCDLxh+zqc1r4sxdS sMmWAA2qW8WiWcqTV02Oq1krJ5bkqY3U9AWxdoEa9mDRf6SNGqUV79dJYEERU2rOhuPS ycdp/fHdL1H/YlZcWO/JHCDr0Gozdm8BAThNfZ8XjvYYiK3KqIMFNLDRQi3TnzrG1mKc FLFQ== X-Gm-Message-State: AOJu0Yzm5M9nSuw8wJyu04Yfl5l3J1BrllRze5yS4kOw9hqTlltGxE1h 18LnlVxtzKG/26qb9+jaHUdHmJEE8icrE2mVxv3WWxppgBpV+5YVbp24k4SsJtL8s6cKPkorLSf L X-Google-Smtp-Source: AGHT+IEQmKusUrgIkGHs2s2w3fJ9kiXHZony6WuM71/t5ZCULWC90/P/ZVgWPld1U98FGwRa7a/Bpw== X-Received: by 2002:a17:903:124e:b0:1dc:cbaa:f5dd with SMTP id u14-20020a170903124e00b001dccbaaf5ddmr970885plh.39.1711062712908; Thu, 21 Mar 2024 16:11:52 -0700 (PDT) Received: from localhost ([2804:14d:7e39:8470:e28:f7d5:8d63:c544]) by smtp.gmail.com with ESMTPSA id q13-20020a17090311cd00b001dd652ef8d6sm402991plh.152.2024.03.21.16.11.51 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 21 Mar 2024 16:11:52 -0700 (PDT) From: Thiago Jung Bauermann To: gdb-patches@sourceware.org Subject: [RFC PATCH 0/3] Fix attaching to process when it has zombie threads Date: Thu, 21 Mar 2024 20:11:46 -0300 Message-ID: <20240321231149.519549-1-thiago.bauermann@linaro.org> X-Mailer: git-send-email 2.41.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, 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 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 Hello, This patch series fixes a GDB hang when attaching to a multi-threaded inferior which happens often (but not always) on aarch64-linux and powerpc64le-linux, as described in PR 31312. See patch 3 for a detailed descripiton of the problem. Patches 1 and 2 are preparatory patches because I want to use existing code to parse the /proc/PID/stat file to get the thread's starttime value, so that GDB and gdbserver aren't fooled by PID reuse. This patch series was tested on native and extended-remote aarch64-linux and armv8l-linux-gnueabihf and no regressions were found, except for the following: When running gdb.threads/detach-step-over.exp on armv8l-linux-gnueabihf extended-remote, sometimes GDBserver dies with: builtin_spawn /home/thiago.bauermann/.cache/builds/gdb-native-aarch32/gdb/testsuite/outputs/gdb.threads/detach-step-over/detach-step-over Remote debugging from host 127.0.0.1, port 56624 Process /home/thiago.bauermann/.cache/builds/gdb-native-aarch32/gdb/testsuite/outputs/gdb.threads/detach-step-over/detach-step-over created; pid = 840876 Attached; pid = 840821 Detaching from process 840821 Attached; pid = 840821 /home/thiago.bauermann/src/binutils-gdb/gdbserver/linux-low.cc:1956: A problem internal to GDBserver has been detected. unsuspend LWP 840821, suspended=-1 The assertion triggered is this one: /* Decrement LWP's suspend count. */ static void lwp_suspended_decr (struct lwp_info *lwp) { lwp->suspended--; if (lwp->suspended < 0) { struct thread_info *thread = get_lwp_thread (lwp); internal_error ("unsuspend LWP %ld, suspended=%d\n", lwpid_of (thread), lwp->suspended); } } Unfortunately for the moment I don't have time to further debug this problem and I didn't want to keep sitting on these patches until I can come back to this issue. Note that of all the testcases in the GDB testsuite, only detach-step-over.exp triggers the GDBserver internal error so it's a localized problem. This is why I'm posting the patch series as an RFC. Considering that it fixes a problem that is causing instability in the testsuite results for aarch64-linux and powerpc64le-linux, does it make sense to commit it as is, and then investigate the GDBserver internal error on armv8l-linux-gnueabihf later? Thiago Jung Bauermann (3): gdb/nat: Use procfs(5) indexes in linux_common_core_of_thread gdb/nat: Factor linux_find_proc_stat_field out of linux_common_core_of_thread gdb/nat/linux: Fix attaching to process when it has zombie threads gdb/nat/linux-osdata.c | 65 +++++++++++++++++++++++++++++++++--------- gdb/nat/linux-osdata.h | 7 +++++ gdb/nat/linux-procfs.c | 19 ++++++++++++ 3 files changed, 77 insertions(+), 14 deletions(-) base-commit: b42aa684f6ff2bce9b8bc58aa89574723f17f1ce