From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com [IPv6:2607:f8b0:4864:20::102e]) by sourceware.org (Postfix) with ESMTPS id AC2D7384640E for ; Wed, 24 Apr 2024 23:15:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org AC2D7384640E 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 AC2D7384640E Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::102e ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714000545; cv=none; b=wyQYufj8rJsXRN0SDOoIdwD146Q/GbdnFwQ4nKbUqTzFkIZxWGY3HSzzriPaDHcEWB3pbAouHRqhKtz/tokK/puZoIzSrjmRzV3F7ICbwulwgVLTVtLCGzch9SC3vwqLupGY/V42ixGoL6NdcM+dwWZdFmrYyXxEbvXsCwIohpQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714000545; c=relaxed/simple; bh=2nJYsewJ1FOzERxu2WXFgbMr2+Mk2m1vsh5GhECik4c=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=MyUf3AHeWkyrQRMcrFgfSy2yv3wroghL6YVkZ+UTNbZEsyoEcJx3abGMmqcEtNtSiqnS+anRMszGWZzm2gwVfNZYqKXtmW4TX8740Urbg+Z4sZRSDTsAziwiK5Bs7hdp1lP2He9gRK7SXVDVZd4iImyWzvow+qtxDKz8xJ5jLxc= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-pj1-x102e.google.com with SMTP id 98e67ed59e1d1-2af800ff18dso382571a91.1 for ; Wed, 24 Apr 2024 16:15:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1714000542; x=1714605342; darn=sourceware.org; h=mime-version:message-id:date:user-agent:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=YFlVOA/9jXac8g2JjfregYTDzsF1VzDOCL1ha+MEmJs=; b=oGTPUDgFTGamYH0NbI73mN/EUXNaeFUgqPqzcjVBaHBD+hpFYYJeFrVCiuIMqXTffq x6mPLvqM7FJ1qtJrWSU9dPhPCFv5pnGk24EEIWe62LyJJFuYAkpY+NMYxUdRq9AyEpfp sgkuuC1sd6R50/0idJLrqjqhIZlekx3pQ7nseN4+4qs33yO81iQI3uPZs2WoJO7Gv6Rb xjSkikg9SgJhzuPW0eTrY7zEebWx9QTVNh7N1cUKDmMuYhEEvyhto0yA8q3xpD/g7YYn KIMbXF/o58TfBl4BP59HzMKT2XrBziGetFqjRhKw74OlQID5w/YEUfF7ogV4XjZbW5kN Zmyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714000542; x=1714605342; h=mime-version:message-id:date:user-agent:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=YFlVOA/9jXac8g2JjfregYTDzsF1VzDOCL1ha+MEmJs=; b=r5kIyExwG7bUFPKJLpIsUiBhXVpRtHeEcl5zSoENXbMUY23XG38VI4z4YH3vRICmA+ m2XLSWW/oG5hirAwbNO9lvuPc1FAULCFD52fb/+R8gT0BcLOqCOreiuiJxiVXh72hhiP +6g73qIwBI1B6LzzjhzHVufOGuiYLWhWlpwXVbhww03FLoJxECY4qpPpf0LLVa2OfsTv 8Cj1w7NyPsnpqBFeiTfV6BbUS+P7OIkqcRfCAscPcJZUE5sJUe4tY+9eyo98iBZYg59x 9aWTwX6VHCYn8t6KWPRoCTVb2xEj3RhdxbIAp/OTRaH7UfWK2rScjUMOwAqmXYWjvln1 kr8w== X-Gm-Message-State: AOJu0YxvNvKe4b8PaPTQNPGT6AeA801vY7SY+7NwD/1pjJBtRwOKd+wr vwUKENAISooX8Cigi1WXtHPQC4wUlsFT4gffbiQbLgGqzw0jROox17p9pBAIaUE= X-Google-Smtp-Source: AGHT+IEGBXcbv27tM5vjHIZN4g3dTNcnXuYHVgrEIhyTzw5hfWRf8S9R2Pdp9Q4ozcsK1rALD2AorA== X-Received: by 2002:a17:90a:bb92:b0:2ac:93e8:7dd5 with SMTP id v18-20020a17090abb9200b002ac93e87dd5mr4106359pjr.0.1714000542430; Wed, 24 Apr 2024 16:15:42 -0700 (PDT) Received: from localhost ([2804:14d:7e39:8470:b65d:315b:9fcb:d747]) by smtp.gmail.com with ESMTPSA id gk1-20020a17090b118100b002a5290ad3d4sm11780047pjb.3.2024.04.24.16.15.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Apr 2024 16:15:42 -0700 (PDT) From: Thiago Jung Bauermann To: Pedro Alves Cc: gdb-patches@sourceware.org, Christophe Lyon , Luis Machado Subject: Re: [PATCH v2 3/3] gdb/nat/linux: Fix attaching to process when it has zombie threads In-Reply-To: <9675ae26-3e85-4acd-8bbb-8de829818cc8@palves.net> (Pedro Alves's message of "Mon, 22 Apr 2024 20:59:37 +0100") References: <20240420055652.819024-1-thiago.bauermann@linaro.org> <20240420055652.819024-4-thiago.bauermann@linaro.org> <9675ae26-3e85-4acd-8bbb-8de829818cc8@palves.net> User-Agent: mu4e 1.12.4; emacs 29.3 Date: Wed, 24 Apr 2024 20:15:39 -0300 Message-ID: <874jbq2vz8.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-4.9 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 List-Id: Pedro Alves writes: > On 2024-04-20 06:56, 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. >> >> This problem causes the following failures: >> >> FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: attach (timeout) >> FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: no new threads (timeout) >> FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: set breakpoint >> always-inserted on (timeout) >> FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: break break_fn (timeout) >> FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: break at break_fn: 1 >> (timeout) >> FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: break at break_fn: 2 >> (timeout) >> FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: break at break_fn: 3 >> (timeout) >> FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: reset timer in the >> inferior (timeout) >> FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: print seconds_left >> (timeout) >> FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: detach (timeout) >> FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: set breakpoint >> always-inserted off (timeout) >> FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: delete all breakpoints, >> watchpoints, tracepoints, and catchpoints in delete_breakpoints (timeout) >> ERROR: breakpoints not deleted >> >> The iteration number is random, and all tests in the subsequent iterations >> fail too, because GDB is stuck in the attach command at the beginning of >> the iteration. >> >> The solution is to make linux_proc_attach_tgid_threads () remember when it >> has already processed a given LWP and skip it in the subsequent iterations. >> >> PR testsuite/31312 >> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31312 >> >> Reviewed-By: Luis Machado > > Approved-By: Pedro Alves Thank you! > BTW, after seeing the other patches after patch #1, I do agree with giving names > to the stat fields. Great. You did bring up interesting points about them though, so it was an interesting exercise. -- Thiago