[Bug gdb/26754] Race condition when resuming threads and one does an exec

["palves at redhat dot com" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=26754

--- Comment #6 from Pedro Alves <palves at redhat dot com> ---
> 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.

Well, I said "that is reported after all threads in the process are exited". 
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 
> 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.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 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.100 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 space
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 never
disappears, it already refuses to die and stays as a zombie when it exits.  I
would prefer to preserve gdb thread id == 1 before / after exec, but that's a
GDB concern, not a kernel interface concern.

Ship it!

-- 
You are receiving this mail because:
You are on the CC list for the bug.