This is an archive of the discontinued LLVM Phabricator instance.

[NativeProcessLinux] Add back synchronisation of thread create events
ClosedPublic

Authored by labath on Apr 23 2015, 5:35 AM.

Details

Summary

Without the synchronisation between the two thread creation events the following case could
happen:

  • threads A and B are running. A hits a breakpoint. We note that we want to stop B.
  • before we could stop it, B creates a new thread C, we get the stop notification for B, but we don't record C's existence yet.
  • we resume B
  • before we get the C notification, B stops again (e.g. hits a breakpoint, gets our SIGSTOP, etc.)
  • we see all known threads have stopped, and we notify LLDB
  • C notification comes, we note it's existence and resume it

> we have an inconsistent state (LLDB thinks we've stopped, but C is running)

I resolve this by doing a blocking wait for for the C notification when we get the creation
notification on the parent (B) thread. This way the two events are synchronised, but we don't
need to introduce the intermediate "launching" state which would complicate handling of thread
states as all code would need to be aware of the third possible state.

Diff Detail

Repository
rL LLVM

Event Timeline

labath updated this revision to Diff 24289.Apr 23 2015, 5:35 AM
labath retitled this revision from to [NativeProcessLinux] Add back synchronisation of thread create events.
labath updated this object.
labath edited the test plan for this revision. (Show Details)
labath added reviewers: chaoren, vharron.
labath added a subscriber: Unknown Object (MLST).
chaoren added inline comments.Apr 23 2015, 10:39 AM
source/Plugins/Process/Linux/NativeProcessLinux.cpp
2315 ↗(On Diff #24289)

I think we should log it anyway.

labath updated this revision to Diff 24361.Apr 24 2015, 12:57 AM

Add more logging.

labath added inline comments.Apr 24 2015, 12:59 AM
source/Plugins/Process/Linux/NativeProcessLinux.cpp
2315 ↗(On Diff #24289)

Done. Please take another look.

chaoren added inline comments.Apr 24 2015, 11:43 AM
source/Plugins/Process/Linux/NativeProcessLinux.cpp
2274 ↗(On Diff #24361)

This should probably be at the end. I don't think GetEventMessage(pid, ...) would work if the thread is running. The thread could have also exited by the time you call waitpid(pid, ...).

2301 ↗(On Diff #24361)

waitpid(tid, ...)?

labath added inline comments.Apr 24 2015, 1:00 PM
source/Plugins/Process/Linux/NativeProcessLinux.cpp
2274 ↗(On Diff #24361)

Woops, that's embarrasing.
Are you OK if I put it right after the GetEventMessage call? (The waitpid should be waiting on the *tid*, of course, so this should not interfere with it).

2301 ↗(On Diff #24361)

Yes, thanks for catching that.

chaoren added inline comments.Apr 24 2015, 2:07 PM
source/Plugins/Process/Linux/NativeProcessLinux.cpp
2274 ↗(On Diff #24361)

That's fine too. I'm just worried that it's easy to forget that there is a thread running, so it's easy to introduce bugs in the future if someone makes some changes to read something from the parent thread. There would need to be two resumes (or a goto, or an ugly giant if), but I think it's worth it.

2301 ↗(On Diff #24361)

Probably doesn't make much of a difference, but wouldn't __WCLONE be more correct than __WALL here?

2322 ↗(On Diff #24361)

GetSignalInfo(tid, ...)?

labath updated this revision to Diff 24462.Apr 27 2015, 3:03 AM

Fix silly copy-paste errors and clean things up.

source/Plugins/Process/Linux/NativeProcessLinux.cpp
2274 ↗(On Diff #24361)

I have put the code in a function and placed the resume at the end.

2301 ↗(On Diff #24361)

I would rather keep WALL. When attaching, we also use WALL even though we are only waiting on a specific thread.

2322 ↗(On Diff #24361)

done.

chaoren accepted this revision.Apr 27 2015, 10:47 AM
chaoren edited edge metadata.

LGTM after this one change:

source/Plugins/Process/Linux/NativeProcessLinux.cpp
2352 ↗(On Diff #24462)

Please only do this if GetEventMessage succeeded.

This revision is now accepted and ready to land.Apr 27 2015, 10:47 AM
This revision was automatically updated to reflect the committed changes.