[Lldb-commits] [PATCH] D93874: [process] fix exec support on Linux

[walter erquinigo via Phabricator via lldb-commits]

wallace added a comment.

Jim, thanks for the pointers! I think we are getting close to the issue. After doing what you asked, I found out the following:

- I set up the state of the lldb debugging the program that will exec right before it execs
- Then I do "continue"
- ThreadPlan::WillResume is invoked, which effectively clears out the m_thread cache. After this, I would expect no calls to ThreadPlan::GetThread until the the new thread list is created
- Then suddenly ThreadList::ShouldReportRun is invoked, which is handling the resume event. It eventually asks the current ThreadPlan ShouldReportRun, which invokes GetPreviousPlan() if m_run_vote is eVoteNoOpinion

  Vote ThreadPlan::ShouldReportRun(Event *event_ptr) {
    if (m_run_vote == eVoteNoOpinion) {
      ThreadPlan *prev_plan = GetPreviousPlan();
      if (prev_plan)
        return prev_plan->ShouldReportRun(event_ptr);
    }
    return m_run_vote;
  }

This triggers ends up invoking GetThread()

  ThreadPlan *GetPreviousPlan() { return GetThread().GetPreviousPlan(this); }

Which causes the incorrect value to be cached.

- After this event is processed, the stop exec happens, but the ThreadPlanBase's m_thread cache is not null, which breaks the invariant that you mentioned

> Keep continuing in the inferior lldb if you have to till you see it get the stop packet that corresponds to the exec. At this point all the thread plans should have no cached threads, so they are going to have to look them up.

I think that the ShouldReportRun is unavoidable at that step, so I thought of a couple of solutions.

- One is to to modify GetPreviousPlan() to something like this

  ThreadPlan *GetPreviousPlan() { return GetThread(/*cache_thread*/ false).GetPreviousPlan(this); }

This allows traversing the thread plan stack without caching the thread. This might be fine because ShouldReportRun is merely looking for any thread plan in the stack with an m_run_vote other than eVoteNoOpinion. It doesn't use the thread for any other reason.

- Another solution is to force clear the m_thread caches in all the ThreadPlans as soon as there's a stop event.

What do you think?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D93874/new/

https://reviews.llvm.org/D93874