From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 0383E3865460; Thu, 19 Nov 2020 21:32:45 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0383E3865460 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 21:32:45 +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 21:32:46 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D26754 --- Comment #5 from Simon Marchi --- Just a precision about this: > I think that we would need a new event, similar to PTRACE_EVENT_EXEC but > that is reported after all threads in the process are exited (and report > their exit) and _before_ the tid of the execing thread is changed. Let's > call it PTRACE_EVENT_ALMOST_EXEC. At this point, like with > PTRACE_EVENT_EXEC (before other threads are reaped), the previous leader > would be in zombie state. The process had already loaded the new address > space when PTRACE_EVENT_ALMOST_EXEC is reported. So if GDB happens to try > to resume the leader just while some other thread execs, it would fail to > ptrace-resume it with ESRCH because it was zombie. GDB would react to > PTRACE_EVENT_ALMOST_EXEC like it reacts to PTRACE_EVENT_EXEC -- by loading > the new symbols, and installing breakpoints in the new address space.=20 > Except it wouldn't destroy the non-leader thread yet -- that would happen= on > PTRACE_EVENT_EXEC. If we look at fs/exec.c in the kernel, around function "de_thread": https://github.com/torvalds/linux/blob/3494d58865ad4a47611dbb427b214cc5227f= a5eb/fs/exec.c It looks like other threads are deleted first, and the new address space is= set up second. What you describes implies that it's the other way around. The way I see it could work is like this. Let's say the leader is 100.100 = and the non-leader is 100.101. 1. non-leader execs 2. all other threads are removed 3. PTRACE_EVENT_ALMOST_EXEC is fired: GDB deletes other threads from its da= ta 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.100= in its data structures, loads the new symbols 7. GDB resumes execution of 100.100 --=20 You are receiving this mail because: You are on the CC list for the bug.=