This is an archive of the discontinued LLVM Phabricator instance.

Add a mutex to guard access to the ThreadPlanStack class
AcceptedPublic

Authored by jingham on Jul 15 2021, 8:47 PM.

Details

Summary
   
We've seen reports of crashes (none we've been able to reproduce
locally) that look like they are caused by concurrent access to a
thread plan stack.  It looks like there are error paths when an
interrupt request to debugserver times out that cause this problem.

The thread plan stack access is never in a hot loop, and there
aren't enough of them for the extra data member to matter, so
there's really no good reason not to protect the access.

Adding the mutex revealed a couple of places where we were
using "auto" in an iteration when we should have been using
"auto &" - we didn't intend to copy the stack - and I fixed
those as well.

Diff Detail

Event Timeline

jingham requested review of this revision.Jul 15 2021, 8:47 PM
jingham created this revision.
Herald added a project: Restricted Project. · View Herald TranscriptJul 15 2021, 8:47 PM

I've also opened D106171 as a potential fix. It could be that we merge both diffs, they aren't mutually exclusive.

lldb/include/lldb/Target/ThreadPlanStack.h
157
lldb/source/Target/ThreadPlanStack.cpp
417
432
JDevlieghere accepted this revision.Jul 16 2021, 2:17 PM
JDevlieghere added inline comments.
lldb/include/lldb/Target/ThreadPlanStack.h
113

Does this actually have to be a recursive mutex?

This revision is now accepted and ready to land.Jul 16 2021, 2:17 PM

I believe it does need to be a reclusive mutex.

kastiglione accepted this revision.Jul 16 2021, 3:23 PM
kastiglione added inline comments.
lldb/include/lldb/Target/ThreadPlanStack.h
113

For example DiscardAllPlans calls DiscardPlan both of which declare a lock_guard.

I believe it does need to be a reclusive mutex.

Yes, I could refactor this to have a no-lock version, but I don't think it's worth complicating things.

Fair enough. LGTM!