From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id D634E385E449; Fri, 15 Mar 2024 21:57:33 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D634E385E449 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1710539853; bh=3YzdetfIH0XA/KjDrNjEk+TV4rSdg+eBEzpgB4enXRY=; h=From:To:Subject:Date:In-Reply-To:References:From; b=X36BTv/Rj68/FQtlCct9g1h9ZOzLdpi8ArOgaAHI8Gc4dSQLGv1WrOxldU3oVbPYc iyunpj3Q6EKyEG/iYW+r9wBS4Ma69B+I4FaRr2+gaRUDcXfyWogvQbtHVS7EZSz1xh ZrghV6bXANDp0kPIdvLRqNwpYNuGP68u3DHlFF24= From: "thiago.bauermann at linaro dot org" To: gdb-prs@sourceware.org Subject: [Bug testsuite/31312] attach-many-short-lived-threads gives inconsistent results Date: Fri, 15 Mar 2024 21:57:32 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: testsuite X-Bugzilla-Version: HEAD X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: thiago.bauermann at linaro dot org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: cel at linux dot ibm.com X-Bugzilla-Target-Milestone: 15.1 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D31312 Thiago Jung Bauermann changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |thiago.bauermann at linaro= dot org --- Comment #16 from Thiago Jung Bauermann --- Hello, (In reply to Tom Tromey from comment #12) > > It then attempts to attach again. At this point, the attach > > times out and all subsequent gdb commands for the rest of the iterations > > all time out. >=20 > It seems unusual to me that a single failure could somehow cause > subsequent ones to fail. Like, why would that be? I also see this on aarch64-linux (sometimes), and I spent a bit of time exploring the problem. I don't know yet what is going on, but I found two interesting behaviours when trying to reproduce manually what the testcase = is doing=C2=B9: 1. Most of the time the attach fails with EPERM (which is the XFAIL case), = but occasionally GDB starts to use 100% of the CPU and never brings back the prompt. At least in my case, this is why a single failure =E2=80=94 e.g., "= iter 8: attach (timeout)" =E2=80=94 causes all the subsequent ones to fail: GDB sim= ply hangs and the testcase can't make forward progress anymore. 2. Just now, the attach command did something surprising: (gdb) attach 2039552 Attaching to process 2039552 Cannot attach to lwp 2689792: Operation not permitted (1), process 26897= 92 is already traced by process 2039527 PID 2039552 is the testcase inferior, and 2039527 is GDB. GDB didn't rep= ort any success in attaching to the process. I haven't digged deep enough to say anything about what exactly is going on yet. --=20 =C2=B9 that is, I'm running the attach-many-short-lived-threads in one term= inal and then repeatedly trying to attach to it from GDB in another terminal --=20 You are receiving this mail because: You are on the CC list for the bug.=