From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id AF79D3857C56; Thu, 19 Nov 2020 23:11:00 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org AF79D3857C56 From: "simark at simark dot ca" To: gdb-prs@sourceware.org Subject: [Bug gdb/26754] Race condition when resuming threads and one does an exec Date: Thu, 19 Nov 2020 23:11:00 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: gdb X-Bugzilla-Version: HEAD X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: simark at simark dot ca X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: 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 X-BeenThere: gdb-prs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-prs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 23:11:00 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D26754 --- Comment #7 from Simon Marchi --- (In reply to Pedro Alves from comment #6) > In #3, I assume that the leader thread will still exist, but be zombie, l= ike > what happens currently with PTRACE_EVENT_EXEC until you reap all threads.= =20 > GDB is free to delete it from its data structures then, it's what we alre= ady > do when the leader exits even without considering exec events -- the lead= er > never disappears, it already refuses to die and stays as a zombie when it > exits. That looks right. Notice that the new event is fired just after that loop (note that these links may become dead if the branch is forced-pushed): https://github.com/compudj/linux-dev/blob/1c9ed9f9b432ccb58e5344c83568e1a66= f52843b/fs/exec.c#L1204-L1220 In that loop, we wait for `leader->exit_state` to become true. It would ma= ke sense that this denotes the zombie state, but I don't actually know. The comment a few lines above says: /* * At this point all other threads have exited, all we have to * do is to wait for the thread group leader to become inactive, * and to assume its PID: */ By "wait for the thread group leader to become inactive", they probably mean "wait for it to become zombie", so again it matches what you say. Also, note that the event is also sent in the else branch of: if (!thread_group_leader(tsk)) { ... } else { ptrace_event(PTRACE_EVENT_EXEC_BEGIN, old_vpid); } To cover for the case where the leader does the exec. > I would prefer to preserve gdb thread id =3D=3D 1 before / after exec, > but that's a GDB concern, not a kernel interface concern. I don't understand what you mean here. --=20 You are receiving this mail because: You are on the CC list for the bug.=