From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 233D33857C56; Thu, 19 Nov 2020 22:57:55 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 233D33857C56 From: "palves at redhat dot com" To: gdb-prs@sourceware.org Subject: [Bug gdb/26754] Race condition when resuming threads and one does an exec Date: Thu, 19 Nov 2020 22:57:55 +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: palves at redhat dot com 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 22:57:55 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D26754 --- Comment #6 from Pedro Alves --- > It looks like other threads are deleted first, and the new address space = is set=20 > up second. What you describes implies that it's the other way around. Well, I said "that is reported after all threads in the process are exited"= .=20 By "all threads" here I was talking about all threads except the leader and= the one that exceed, like how PTRACE_EVENT_EXEC event also works. > It looks like other threads are deleted first, and the new address space = is set=20 > up second. What you describes implies that it's the other way around. It looks more like you're talking about the order of changing the exec'ing thread's tid to the tgid vs setting up the new address space. OK. > The way I see it could work is like this. Let's say the leader is 100.10= 0 and=20 > the non-leader is 100.101. >=20 > 1. non-leader execs > 2. all other threads are removed > 3. PTRACE_EVENT_ALMOST_EXEC is fired: GDB deletes other threads from its = data structures > 4. GDB resumes execution of 100.101 > 5. kernel renames 100.101 into 100.100 and sets up new address space > 6. PTRACE_EVENT_EXEC is fired: GDB updates the ptid from 100.101 to 100.1= 00 in > its data structures, loads the new symbols > 7. GDB resumes execution of 100.100 OK, yeah, the main difference is that I was saying that the new address spa= ce would be created between #2 and #3, and GDB would load the new symbols in #3 already. I think what you have should work too, and is nicer in that the PTRACE_EVENT_EXEC handling continues the same and PTRACE_EVENT_ALMOST_EXEC = is a smaller incremental change, a pure addition. I like it. In #3, I assume that the leader thread will still exist, but be zombie, like what happens currently with PTRACE_EVENT_EXEC until you reap all threads. = GDB is free to delete it from its data structures then, it's what we already do when the leader exits even without considering exec events -- the leader ne= ver disappears, it already refuses to die and stays as a zombie when it exits. = I would prefer to preserve gdb thread id =3D=3D 1 before / after exec, but th= at's a GDB concern, not a kernel interface concern. Ship it! --=20 You are receiving this mail because: You are on the CC list for the bug.=