From patchwork Mon Mar 25 19:57:44 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Pedro Alves X-Patchwork-Id: 87641 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id E88B63858CDB for ; Mon, 25 Mar 2024 19:58:18 +0000 (GMT) X-Original-To: gdb-patches@sourceware.org Delivered-To: gdb-patches@sourceware.org Received: from mail-qk1-f180.google.com (mail-qk1-f180.google.com [209.85.222.180]) by sourceware.org (Postfix) with ESMTPS id A5C003858D33 for ; Mon, 25 Mar 2024 19:57:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A5C003858D33 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org A5C003858D33 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=209.85.222.180 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1711396672; cv=none; b=YHZN+JXJSugeUS9z/LoL5msBtU6mVdor/PFlyE857nBfZrZNjdKalz+7n19KIeM+Y1KxCqEZ6pCdCUYsHAV+ZQ+skNN98qyuldX2n2yyXoVxmMCtzWsHSTzLCqlUziS4UggnTmWC7gCIyfwXfYwfAL09R+FkSmOduTgXHJJS6EQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1711396672; c=relaxed/simple; bh=v083zYIUfEngtwY4WVMoNMd/dUr2moCYbeXMdgPx1B8=; h=Message-ID:Date:MIME-Version:Subject:From:To; b=JixYnClWYpg6FknVNnuf0T+V6G93CXg/EQ2/s+B69BwjoW3XRs6qWmf/E8rQfp9240kZKfLxNE7Z80XYrjFpZEFKe5S0xeSUkpmZOhhpCD5JbDN1u6tKUU+op/6pYI7AUuXKV6fUuFbkurVl3pvJq4xBnZEmV8hmktyKB18mFI0= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-qk1-f180.google.com with SMTP id af79cd13be357-78a2290b48eso375110385a.3 for ; Mon, 25 Mar 2024 12:57:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711396669; x=1712001469; h=content-transfer-encoding:in-reply-to:to:references:cc:from :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Z1rByI1iahHRWQbdApauxU1ZOG/natXJIQiw+ztkVjs=; b=CwArjJ09DYb4dGfbXFrzhMKxtfdCXkVjq/Wydl1joCXsRr8VogDF/jRzaFgYYfF9W0 cI38Ds7XwRHaBLiJxX7/r+yQMsOaniqwxAA/09npZsStmIVnB7rwDImse9SGeh3HSkrv +8+relA/1DnETSrftdt4qGngHiMlTKROgEg1Uoc17GfA7qRj7FzpHAwlZQ1kb6yonb0G oAEeLxluThyrW7BbOuiPID82zUlql2cbVCP7PiCAgPwZjClLuVaOtxFxCkxjF9gcIWit MnOob+6bHd2HJq90S6O60I9rnGOdRieOxMRJbsbHXQT3G4oewivnvvjsfFu54mAZkRjp Kfrg== X-Gm-Message-State: AOJu0YyyXwIxvZbQJSLis4YYWApl9+ZwB/2R7Sfe8LrnTIHgXoiJ5pic vVkCR0NiVyVcmxRzY+QV1Xrr6Jqz6t+/AjXAXWFs6+LBHOjb4owU1JPCzrXT3Q0= X-Google-Smtp-Source: AGHT+IG4GlDi0eYzYRQqQbyU25vdWSx0jHFLT3I0ctNGSmEj4lyMroeGsM6M/bU42ep/iAP1LI0JQg== X-Received: by 2002:ad4:5bea:0:b0:696:9aae:5d9f with SMTP id k10-20020ad45bea000000b006969aae5d9fmr276016qvc.3.1711396669480; Mon, 25 Mar 2024 12:57:49 -0700 (PDT) Received: from ?IPV6:2001:8a0:f918:ab00:614:7511:27a5:e9eb? ([2001:8a0:f918:ab00:614:7511:27a5:e9eb]) by smtp.gmail.com with ESMTPSA id cy17-20020a05621418d100b0068f6e1c3582sm3630479qvb.146.2024.03.25.12.57.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 25 Mar 2024 12:57:49 -0700 (PDT) Message-ID: Date: Mon, 25 Mar 2024 19:57:44 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: [PATCH] New testcase gdb.threads/leader-exit-attach.exp (PR threads/8153) Content-Language: en-US From: Pedro Alves Cc: Eli Zaretskii References: <20240322193030.1235342-1-pedro@palves.net> <86wmptzc2f.fsf@gnu.org> <2544bf99-997c-4065-8ae9-4dfb0b07d17b@palves.net> To: "gdb-patches@sourceware.org" In-Reply-To: <2544bf99-997c-4065-8ae9-4dfb0b07d17b@palves.net> X-Spam-Status: No, score=-11.1 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, GIT_PATCH_0, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, KAM_SHORT, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, 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+patchwork=sourceware.org@sourceware.org On 2024-03-25 19:36, Pedro Alves wrote: > On 2024-03-23 06:39, Eli Zaretskii wrote: >>> From: Pedro Alves >>> Date: Fri, 22 Mar 2024 19:30:30 +0000 >>> >>> While working on Windows non-stop mode, I managed to introduce a bug >>> that led to fake_create_process being called. That then resulted in >>> GDB crashes later on, because fake_create_process added a thread with >>> an incorrect ptid for this target. It is putting dwThreadId in the >>> tid field of the ptid instead of on the lwp field. This is fixed by >>> this patch. >>> >>> I do however wonder why nobody has seen it this long. >> >> AFAIU, to actually see the bug, one would need to attach GDB to a >> process whose main thread has exited, is that true? If so, I'm not >> surprised this bug was not reported: it's unusual for the main thread >> to exit without shutting down the process, and the need to attach to >> such a process (as opposed to having it run from GDB to begin with) >> makes that even more rare. And finally, not every bug is reported by >> the first person who sees it the first time, right? > > Yes, that could be the reason. But it could also be because the brokenness with the > Windows debug API that Chris was seeing only happens on Windows versions we no > longer claim support for (i.e., earlier than Windows XP). > > Anyhow, the patch is pretty obvious on its own, so I went ahead and merged it > without that blurb in the commit log, like below. > > I also wrote a testcase that exercises the scenario in question. I'll post > that next. Here's said testcase. Only two decades between original fix and testcase, not too bad. :-) While writing this, I stumbled on server/31554, and I filed it in bugzilla, and added a kfail here, to avoid falling deeper down the rabbit hole. I also filed server/31555 for the can't-attach-to-zombie-task on Linux, and marked it as kfail instead of xfail as there may be a workaround for that. (Attach to all the process's threads anyhow. We'd not get an exit status for the final process exit, but I think we could live without it). From ff9c3b19e5c876ed8e5cb5f45f1e3a9873010991 Mon Sep 17 00:00:00 2001 From: Pedro Alves Date: Mon, 25 Mar 2024 15:17:02 +0000 Subject: [PATCH] New testcase gdb.threads/leader-exit-attach.exp (PR threads/8153) Add a new testcase for exercising attaching to a process after its main thread has exited. This is not possible on Linux, the kernel does not allow attaching to a zombie task, so the test is kfailed there. It is possible however on Windows at least, and was the scenario addressed by the Windows backend fix in https://sourceware.org/legacy-ml/gdb-patches/2003-12/msg00479.html, nowadays PR threads/8153, back in 2003. Passes cleanly on Cygwin. KFAILed on GNU/Linux native and gdbserver. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=8153 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31554 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31555 Change-Id: Ib554f92f68c965bb4603cdf2aadb55ca45ded53b --- .../gdb.threads/leader-exit-attach.exp | 87 +++++++++++++++++++ 1 file changed, 87 insertions(+) create mode 100644 gdb/testsuite/gdb.threads/leader-exit-attach.exp base-commit: ccf3148e3133f016a8e1484e85e5e4d8c271c4f0 diff --git a/gdb/testsuite/gdb.threads/leader-exit-attach.exp b/gdb/testsuite/gdb.threads/leader-exit-attach.exp new file mode 100644 index 00000000000..c1ed1baaa67 --- /dev/null +++ b/gdb/testsuite/gdb.threads/leader-exit-attach.exp @@ -0,0 +1,87 @@ +# Copyright (C) 2024 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 . + +# Test attaching to a program after its main thread has exited. + +require can_spawn_for_attach + +standard_testfile leader-exit.c + +if {[build_executable "failed to prepare" $testfile $srcfile {debug pthreads}] == -1} { + return +} + +set escapedbinfile [string_to_regexp ${binfile}] + +set test_spawn_id [spawn_wait_for_attach $binfile] +set testpid [spawn_id_get_pid $test_spawn_id] + +# Wait a bit for the leader thread to exit, before attaching. +sleep 2 + +clean_restart ${binfile} + +# Save this early as we may not be able to talk with GDBserver anymore +# when we need to check it. +set is_gdbserver [target_is_gdbserver] + +# True if successfully attached. +set attached 0 + +gdb_test_multiple "attach $testpid" "attach" { + -re "Attaching to process $testpid failed.*" { + # GNU/Linux gdbserver. Linux ptrace does not let you attach + # to zombie threads. + setup_kfail "gdb/31555" *-*-linux* + fail $gdb_test_name + } + -re "warning: process $testpid is a zombie - the process has already terminated.*" { + # Native GNU/Linux. Linux ptrace does not let you attach to + # zombie threads. + setup_kfail "gdb/31555" *-*-linux* + fail $gdb_test_name + } + -re "Attaching to program: $escapedbinfile, process $testpid.*$gdb_prompt $" { + pass $gdb_test_name + set attached 1 + } +} + +# With gdbserver, after we failed to attach, we hit PR server/31554: +# print $_inferior_thread_count +# Remote connection closed +# (gdb) KFAIL: gdb.threads/leader-exit-attach.exp: get valueof "$_inferior_thread_count" +if {!$attached && $is_gdbserver} { + setup_kfail "server/31554" "*-*-*" +} + +set thread_count [get_valueof "" "\$_inferior_thread_count" -1] + +if {$thread_count == -1} { + kill_wait_spawned_process $test_spawn_id + return +} + +if {$attached} { + # Check that we have at least one thread. We can't assume there + # will only be exactly one thread, because on some systems, like + # Cygwin, the runtime spawns extra threads. Also, on Windows, + # attaching always injects one extra thread. + gdb_assert {$thread_count >= 1} +} else { + gdb_assert {$thread_count == 0} +} + +kill_wait_spawned_process $test_spawn_id