Skip to content

[lldb] Guard SBFrame/SBThread methods against running processes #152020

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
+508 −384
Open

[lldb] Guard SBFrame/SBThread methods against running processes #152020

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 4 additions & 0 deletions lldb/include/lldb/API/SBFrame.h
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -233,6 +233,10 @@ class LLDB_API SBFrame {

void SetFrameSP(const lldb::StackFrameSP &lldb_object_sp);

/// Return an SBValue with an error message warning that the process is not
/// currently stopped.
Comment on lines +236 to +237
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: The "error message warning" is somewhat confusing. How about:

Suggested change
/// Return an SBValue with an error message warning that the process is not
/// currently stopped.
/// Return an SBValue containing an error message that warns the process is not currently stopped.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At the SB API level, if you are getting the ExecutionContext from an ExecutionContextRef represented by a Target, Process, Thread or Frame you should also hold the API mutex. There are some cases where we don't actually require a process. For instance SBTarget::CreateValueFromAddress can work on either a live process that's stopped or to look at static data on a non-running target. But those seem like they are in the minority, and in that case, for instance, you could easily do:

if (!process || stop_locker.IsLocked())

so that wouldn't be particularly awkward.

I can't think of a good reason why you would want to drop the API lock before the stop lock or vice versa. There's the one place where Felipe swaps the stop_locker originally set for another, so long as this doesn't make that particularly awkward, this seems doable.

static SBValue CreateProcessIsRunningExprEvalError();

lldb::ExecutionContextRefSP m_opaque_sp;
};

Expand Down
5 changes: 5 additions & 0 deletions lldb/include/lldb/Host/ProcessRunLock.h
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -41,9 +41,14 @@ class ProcessRunLock {
class ProcessRunLocker {
public:
ProcessRunLocker() = default;
ProcessRunLocker(ProcessRunLocker &&other) : m_lock(other.m_lock) {
other.m_lock = nullptr;
}

~ProcessRunLocker() { Unlock(); }

bool IsLocked() const { return m_lock; }

// Try to lock the read lock, but only do so if there are no writers.
bool TryLock(ProcessRunLock *lock) {
if (m_lock) {
Expand Down
9 changes: 6 additions & 3 deletions lldb/include/lldb/Target/ExecutionContext.h
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -11,6 +11,7 @@

#include <mutex>

#include "lldb/Host/ProcessRunLock.h"
#include "lldb/Target/StackID.h"
#include "lldb/lldb-private.h"

Expand Down Expand Up @@ -318,11 +319,13 @@ class ExecutionContext {
// These two variants take in a locker, and grab the target, lock the API
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This comment isn't correct anymore.
You should mention that IF the ExecutionContextRef coming in has a process, it will try to lock the stop locker and won't fill anything in below the process. But if the exe_ctx_ref doesn't have a process, the stop_locker won't get locked. That's fairly obvious, but still worth making clear.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's also worth pointing out that IF the stop_locker is locked, the process and target have to be valid, so you don't need to check for that after checking the stop_locker...

// mutex into locker, then fill in the rest of the shared pointers.
ExecutionContext(const ExecutionContextRef &exe_ctx_ref,
std::unique_lock<std::recursive_mutex> &locker)
: ExecutionContext(&exe_ctx_ref, locker) {}
std::unique_lock<std::recursive_mutex> &locker,
ProcessRunLock::ProcessRunLocker &stop_locker)
: ExecutionContext(&exe_ctx_ref, locker, stop_locker) {}

ExecutionContext(const ExecutionContextRef *exe_ctx_ref,
std::unique_lock<std::recursive_mutex> &locker);
std::unique_lock<std::recursive_mutex> &locker,
ProcessRunLock::ProcessRunLocker &stop_locker);
// Create execution contexts from execution context scopes
ExecutionContext(ExecutionContextScope *exe_scope);
ExecutionContext(ExecutionContextScope &exe_scope);
Expand Down
Loading
Loading