From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id xPhJE163/WWPvREAWB0awg (envelope-from ) for ; Fri, 22 Mar 2024 12:52:46 -0400 Received: by simark.ca (Postfix, from userid 112) id 3F9381E0C0; Fri, 22 Mar 2024 12:52:46 -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 2A6B91E08C for ; Fri, 22 Mar 2024 12:52:44 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id B42D2385841A for ; Fri, 22 Mar 2024 16:52:43 +0000 (GMT) Received: from mail-wr1-f53.google.com (mail-wr1-f53.google.com [209.85.221.53]) by sourceware.org (Postfix) with ESMTPS id 9A7153858D28 for ; Fri, 22 Mar 2024 16:52:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9A7153858D28 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 9A7153858D28 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=209.85.221.53 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1711126346; cv=none; b=CBiIX5j96Lj8fzC7XGH6tblKpVItqJLXkA4m6iUR62IdpL3swPCPtq1lI652cGkZfCg4nOvaBEcFL/qSfYoyetjRaLNrtzsjD8h8vhyG27BdQHf46ZowELtVtQNugbKKB0+WqpGjT5WV5E1lmNOzU1zQZANElLb7jYS+nt/OKMA= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1711126346; c=relaxed/simple; bh=l8NtMUhwONPiDMJRsWks6/iFrauXW8V2kyw8mAPF4GM=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=yEzMXRrp8KXwioTB/4v6wz1KPQQfp08IM3ZB8Fg6JdHk/MD3EVqCySwTEhEvp0CFDeGRLILmOFdTkmYdNCKbGSmXv8ZGclRzprjO25plFhoFpkE56YpKwgoNThjVB8TeZmCRxlYdtZvLNSvyAy/DueLObhsmDaAjDV27pxU/IiA= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-wr1-f53.google.com with SMTP id ffacd0b85a97d-33ececeb19eso1236598f8f.3 for ; Fri, 22 Mar 2024 09:52:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711126334; x=1711731134; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=DNx9pzVWrHt0/siB368Onw6vvnp8V1Z1P7oABXhmheo=; b=hXK3MCq5fBXz/ykWViWOcwlAmfsfgDbtJ6QL3ZqiESM70vS2CiZiTDWeV2Cz1uHohv HLMyzTipzKX95qXHmO41QFugnjRZmURyrySv0/fiw07aPX5AjjA03+15QghgijkHSSrk aeKUkfcQdv3PAU81w9+idKrwAPfM5PYUKILvIc6S2Um1YmMkItNVCnlhz4vX9sykRVMT QuAfyxDbtND0zfFvAF6oL26pFkkS9IgkYtXhbGqBIfNfFh7RYu9LIvRW/Sfe1p4jR7OG lE6Isljy+1UzjiJR1GcezgNeBndz9Zl3fkNEK+pkV0az7+iHXDgNgjAI+qh64lQZpG90 Vz3g== X-Forwarded-Encrypted: i=1; AJvYcCWSkB0N8KisY6zTxLxvN0HPlNCOK2/tUxzOYl1frs2cj2GIzvwzwHvNGY3I6uFqXPL6sETljMCYeN4kwIBJRc/w5riwT2kJgr+G+g== X-Gm-Message-State: AOJu0YxM/axLjXFSWmw0y48ngqweiEAZd/OBxpp+YQDmDhJe7BTQbISB oXKkTz8gXPYIclN1S2adufLtK+auJiJhz/2/V8/MHqa/WMI3D2u4IUsh4+Az X-Google-Smtp-Source: AGHT+IHZNgNBGYV+K/qssj5XN++cvQdpjFxm1q7EXX0Srqttp7P+EihJO4hr/tC0/YsbBd7UUBQS8g== X-Received: by 2002:adf:f20e:0:b0:33e:3bf3:a097 with SMTP id p14-20020adff20e000000b0033e3bf3a097mr2037143wro.26.1711126334015; Fri, 22 Mar 2024 09:52:14 -0700 (PDT) Received: from ?IPV6:2001:8a0:f918:ab00:3ba9:feec:1922:9a68? ([2001:8a0:f918:ab00:3ba9:feec:1922:9a68]) by smtp.gmail.com with ESMTPSA id v16-20020a5d5910000000b003418364032asm2429427wrd.112.2024.03.22.09.52.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 22 Mar 2024 09:52:13 -0700 (PDT) Message-ID: Date: Fri, 22 Mar 2024 16:52:09 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH 3/3] gdb/nat/linux: Fix attaching to process when it has zombie threads Content-Language: en-US To: Thiago Jung Bauermann , gdb-patches@sourceware.org References: <20240321231149.519549-1-thiago.bauermann@linaro.org> <20240321231149.519549-4-thiago.bauermann@linaro.org> From: Pedro Alves In-Reply-To: <20240321231149.519549-4-thiago.bauermann@linaro.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.5 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no 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 On 2024-03-21 23:11, Thiago Jung Bauermann wrote: > When GDB attaches to a multi-threaded process, it calls > linux_proc_attach_tgid_threads () to go through all threads found in > /proc/PID/task/ and call attach_proc_task_lwp_callback () on each of > them. If it does that twice without the callback reporting that a new > thread was found, then it considers that all inferior threads have been > found and returns. > > The problem is that the callback considers any thread that it hasn't > attached to yet as new. This causes problems if the process has one or > more zombie threads, because GDB can't attach to it and the loop will > always "find" a new thread (the zombie one), and get stuck in an > infinite loop. > > This is easy to trigger (at least on aarch64-linux and powerpc64le-linux) > with the gdb.threads/attach-many-short-lived-threads.exp testcase, because > its test program constantly creates and finishes joinable threads so the > chance of having zombie threads is high. Hmm. How about simply not restarting the loop if attach_lwp tries to attach to a zombie lwp (and silently fails)? I.e., in gdb, make attach_proc_task_lwp_callback return false/0 here: if (ptrace (PTRACE_ATTACH, lwpid, 0, 0) < 0) { int err = errno; /* Be quiet if we simply raced with the thread exiting. EPERM is returned if the thread's task still exists, and is marked as exited or zombie, as well as other conditions, so in that case, confirm the status in /proc/PID/status. */ if (err == ESRCH || (err == EPERM && linux_proc_pid_is_gone (lwpid))) { linux_nat_debug_printf ("Cannot attach to lwp %d: thread is gone (%d: %s)", lwpid, err, safe_strerror (err)); return 0; <<<< NEW RETURN } Similar thing for gdbserver, of course. Pedro Alves