From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oo1-xc29.google.com (mail-oo1-xc29.google.com [IPv6:2607:f8b0:4864:20::c29]) by sourceware.org (Postfix) with ESMTPS id 09B703858D39 for ; Wed, 10 Apr 2024 04:00:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 09B703858D39 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 09B703858D39 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::c29 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712721608; cv=none; b=MoS8275pM468LFTTxCfrQDTUOzMLa4JWrQDRB8JJcuk1J1mUCzHyBLv4BjNvDNURqtfpWJPzY9Iq99hSYdpL42KPHUT9nu/ftupU6jNTGgnxFdrWonZmmxJ5bkZFBWZmdg13MVLiPIwdVGHbDhtOR4EaqJX01YQI5PM34zomVOo= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712721608; c=relaxed/simple; bh=8GZpMsouoKBlwXoD66sohmEiz96jyslAMtBnPjW4IrQ=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=BCs57gp7vNZa8epUwCO6kwwgNUPNmSB5m9FjSagj+AHdJc9dfGnOMEF8/DUQZlJIHBC8ncheP1L3cgBT07ZLy3x84QM+FwLxFa8wJUPYO1LJYs8rqw3F20A1QpTr50Z4AgtAngUKHf3NsLyH9VQW0G2nYX2TA20u6yMxGuzwXpM= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-oo1-xc29.google.com with SMTP id 006d021491bc7-5aa12c21ff4so2486085eaf.3 for ; Tue, 09 Apr 2024 21:00:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1712721604; x=1713326404; 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=HyW/j/J4Vw7D6nPojntViwomiOCiiLLunjp3EkX8qcM=; b=V4H1DidAxeaCEAuYpAviA4oQMslERUB7YmLpMYRKrpBjiZrCdBM+KxvPYAwUNsRimV c5/3Lmj2QPm/uOxF0UnXG5FZB8h9HsLDSJqvGoAimqafVHsKui+ZtY73570gtnWTNJDJ +/3sdPMBqPgGMsM+PQ44nhfnz+sTkLSCDoEPzZTClskv2tByzReTJZVfhKR8jbKMYHje vYioVM/sPrzHZ+lVh1iyfrvpkYfrfdZVXyGFkIgXQE12Bk/SkEAWp2+6ofILdKgXTOG5 RIxUGjajo8bt5nCB8QPIx1/S2AUJ23JnaRsw2j/2xJzVZnMTbaD8r642sYNW0vrV3Gnr nRZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712721604; x=1713326404; 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=HyW/j/J4Vw7D6nPojntViwomiOCiiLLunjp3EkX8qcM=; b=mTpTXLsHMF4J+ogeecxbL1mz9N+idQIgtobgfmsR2Xt8abgWMgI4PIfUWTW775TVf+ 1Nc0i0QziRB9dNNQ3WqbfnCLj5bh70aPl3tJA2N+nYWBws/Ea0d8g+Yf/LdUhKfAgXol E473SYfNjH+zRtt2+vOt4kQXrQhTaopHalFxIm8s9mDevm7DfAPcutTusUuKkcnimfv5 wvF+o7idXISM/nqzHR696iQNFDpMTZi3h+QRGb9z/LuVQHHqRwqqlN/qkkdpZo6UCfcY s7fldL87agaqrmpNqiOzkIYZC8IUkyLsGhg8vDDIuJ6/TXVuWFdSn95c49Nf5DVfbCln UGQA== X-Gm-Message-State: AOJu0YxJy/fRAtzMzO8PAWkT9DM3g9mNBmfgIELKtiodLs4+tauigVfp iRA8fkcNY5rNPKdYdy9DBdtOUmetuMkAthhZOvu2NQWxacFH/cLEJHAOzrfRw4E= X-Google-Smtp-Source: AGHT+IEKPxmAszoVyo8Mxq5KLasro96JEA4X5C/z/6LP0ZkXUSbJ5yEnJ5MjD/8QVXgfwun6J9Rc0Q== X-Received: by 2002:a05:6808:f8b:b0:3c6:805:4889 with SMTP id o11-20020a0568080f8b00b003c608054889mr1490566oiw.17.1712721603089; Tue, 09 Apr 2024 21:00:03 -0700 (PDT) Received: from localhost ([2804:14d:7e39:8470:c4e1:a7b4:e866:e467]) by smtp.gmail.com with ESMTPSA id p11-20020a056a000a0b00b006eacefd8fabsm9205374pfh.64.2024.04.09.21.00.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 09 Apr 2024 21:00:02 -0700 (PDT) From: Thiago Jung Bauermann To: Bernd Edlinger Cc: "gdb-patches@sourceware.org" , Andrew Burgess Subject: Re: [PATCH v3] Fix sporadic XFAILs in gdb.threads/attach-many-short-lived-threads.exp In-Reply-To: (Bernd Edlinger's message of "Sun, 7 Apr 2024 10:42:31 +0200") References: User-Agent: mu4e 1.12.2; emacs 29.3 Date: Wed, 10 Apr 2024 00:59:58 -0300 Message-ID: <875xwpq341.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-11.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,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: Bernd Edlinger writes: > This is about random test failures like those: > > XFAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 6: attach (EPERM) > XFAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 7: attach (EPERM) > XFAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: attach (EPERM) > XFAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 9: attach (EPERM) > XFAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 10: attach (EPERM) > > The reason for this effect is apparently as follows: > > There is a race condition when gdb tries to attach a thread but the > thread exits at the same time. Normally when that happens the return > code of ptrace(PTRACE_ATTACH, x) is EPERM, which could also have other > reasons. To detect the true reason, we try to open /proc//status > which normally fails in that situation, but it may happen that the > fopen succeeds, and the thread disappears while reading the content, > then linux_proc_pid_get_state fails to find the "State:" line. > Since there is no other possible reason why this can happen, > use that as an indication that the thread has most likely exited. > --- > gdb/nat/linux-procfs.c | 11 +++-------- > 1 file changed, 3 insertions(+), 8 deletions(-) > > v2: from kernel code review, it seems the missing "State:" > can only happen if the thread disappeared, so no need to > look at errno at all here. As I said in v1 of this patch, my reading of the kernel code (function task_state in linux/fs/proc/array.c) agrees with the statement above, but I'm not confident in my conclusion. The reason is that it's tricky to understand the effect of kernel preemption as well as simultaneous execution of "competing" code in a different CPU. Case in point: in the beginning of task_state, there's a block enclosed in rcu_read_lock *and* inside that block there's also some code within task_lock. Why both are necessary? I don't know. And the weirdest thing to me is that the part which reads the task state for the "State:" line isn't protected by either of those. My uninformed assumption would be that it would be best if it were. So unfortunately I don't feel comfortable enough giving my Reviewed-by: to this patch, even though I think it's probably right. I would defer to Pedro, who wrote this code originally, in commit 8784d56326e7 ("Linux: on attach, attach to lwps listed under /proc/$pid/task/"). It was a long time ago, but perhaps he remembers why he decided to assume that there could be a live task with no "State:" line in its status file. > v3: update commit message. > > diff --git a/gdb/nat/linux-procfs.c b/gdb/nat/linux-procfs.c > index e2086952ce6..8d46d5bf289 100644 > --- a/gdb/nat/linux-procfs.c > +++ b/gdb/nat/linux-procfs.c > @@ -157,17 +157,12 @@ linux_proc_pid_is_gone (pid_t pid) > enum proc_state state; > > have_state = linux_proc_pid_get_state (pid, 0, &state); > - if (have_state < 0) > + if (have_state <= 0) > { > - /* If we can't open the status file, assume the thread has > - disappeared. */ > + /* If we can't open the status file or there is no "State:" line, > + assume the thread has disappeared. */ > return 1; > } > - else if (have_state == 0) > - { > - /* No "State:" line, assume thread is alive. */ > - return 0; > - } > else > return (state == PROC_STATE_ZOMBIE || state == PROC_STATE_DEAD); > } -- Thiago