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

["simark at simark dot ca" <sourceware-bugzilla@sourceware.org>]

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

--- Comment #7 from Simon Marchi <simark at simark dot ca> ---
(In reply to Pedro Alves from comment #6)
> 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.

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/1c9ed9f9b432ccb58e5344c83568e1a66f52843b/fs/exec.c#L1204-L1220

In that loop, we wait for `leader->exit_state` to become true.  It would make
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 == 1 before / after exec,
> but that's a GDB concern, not a kernel interface concern.

I don't understand what you mean here.

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