[PATCH] D47609: [lldb, process] Fix occasional hang when launching a process in LLDB

[Jim Ingham via Phabricator via llvm-commits]

jingham added a comment.

Launch and attaching are weird because they happen before you have a private state thread (or if there is one it is explicitly paused), so the events don't flow as they normally would.  So neither launch nor attach are relying on a private eStateLaunching event.

Looking at the code, only FreeBSD and Windows call SetPrivateState(eStateLaunching).  When I do "run" on macOS I see:

(lldb) log enable lldb state
(lldb) run

  Process::SetPublicState (state = launching, restarted = 0)
  Process::SetPrivateState (stopped)
  Process::SetPrivateState (stopped) stop_id = 1
  Process::SetPublicState (state = stopped, restarted = 0)
  Process::SetPublicState (stopped) -- unlocking run lock
  Process::SetPrivateState (running)
  Process::SetPublicState (state = running, restarted = 0)

The private eStateLaunching event shouldn't be needed on Windows either, and I think that it is just causing trouble.  What happens if you just remove the SetPrivateState(eStateLaunching) call?  If that fixes the issue, I'd rather do it that way, since that makes all the platforms regular.

Then we need to find some convenient place to document these expectations...

BTW I'm not disagreeing with your analysis of the current uses of WaitForProcessStopPrivate.  However, if you change it the way that you are suggesting, it will no longer be a generally useable function, it could only be used in in the narrow cases you describe.  So if we have to change it as you are suggesting, we should change its name to something more descriptive of its reduced functionality.  But again, if removing the SetPrivateState(eStateLaunching) fixes the problem, I'd rather do it that way.

As an aside, the comment on line 2691 seems to have wandered out of place - presumably when this code got refactored?  It doesn't make sense here...


Repository:
  rL LLVM

https://reviews.llvm.org/D47609