This is an archive of the discontinued LLVM Phabricator instance.

[lldb] Fix ThreadedCommunication races
ClosedPublic

Authored by labath on Sep 7 2022, 2:43 AM.

Details

Summary

The Read function could end up blocking if data (or EOF) arrived just as
it was about to start waiting for the events. This was only discovered
now, because we did not have unit tests for this functionality before.
We need to check for data *after* we start listening for incoming
events. There were no changes to the read thread code needed, as we
already use this pattern in SynchronizeWithReadThread, so I just updated
the comments to make it clear that it is used for reading as well.

Diff Detail

Event Timeline

labath created this revision.Sep 7 2022, 2:43 AM
Herald added a project: Restricted Project. · View Herald TranscriptSep 7 2022, 2:43 AM
labath requested review of this revision.Sep 7 2022, 2:43 AM
Herald added a project: Restricted Project. · View Herald TranscriptSep 7 2022, 2:43 AM
labath added a comment.Sep 7 2022, 2:48 AM

I've only seen one flake on linux so far, but the windows bot seems more susceptible to this problem.

mgorny added inline comments.Sep 7 2022, 3:50 AM
lldb/source/Core/ThreadedCommunication.cpp
113–119

Can you think of any reason not to move listener setup before the first GetCachedBytes() call instead of duplicating it?

labath added inline comments.Sep 7 2022, 4:02 AM
lldb/source/Core/ThreadedCommunication.cpp
113–119

The only possible reason is "efficiency" (avoiding the creation of the listener and all that goes with it). But I'm definitely not convinced that this actually matters.

mgorny accepted this revision.Sep 7 2022, 6:50 AM

Thanks for noticing and fixing this.

lldb/source/Core/ThreadedCommunication.cpp
113–119

Ok, I'm not bent on it either way.

This revision is now accepted and ready to land.Sep 7 2022, 6:50 AM
This revision was automatically updated to reflect the committed changes.