[all-commits] [llvm/llvm-project] fc4370: [lldb] Use objc_getRealizedClassList_trylock on ma...

[Jonas Devlieghere via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: fc43703481d858351a72d7ea6f439f4f682ba351
      https://github.com/llvm/llvm-project/commit/fc43703481d858351a72d7ea6f439f4f682ba351
  Author: Jonas Devlieghere <jonas at devlieghere.com>
  Date:   2022-06-08 (Wed, 08 Jun 2022)

  Changed paths:
    M lldb/packages/Python/lldbsuite/test/decorators.py
    M lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp
    M lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.h
    M lldb/test/API/lang/objc/conflicting-class-list-function-from-user/TestObjCClassListFunctionFromUser.py

  Log Message:
  -----------
  [lldb] Use objc_getRealizedClassList_trylock on macOS Ventura and later

In order to avoid stranding the Objective-C runtime lock, we switched
from objc_copyRealizedClassList to its non locking variant
objc_copyRealizedClassList_nolock. Not taking the lock was relatively
safe because we run this expression on one thread only, but it was still
possible that someone was in the middle of modifying this list while we
were trying to read it. Worst case that would result in a crash in the
inferior without side-effects and we'd unwind and try again later.

With the introduction of macOS Ventura, we can use
objc_getRealizedClassList_trylock instead. It has semantics similar to
objc_copyRealizedClassList_nolock, but instead of not locking at all,
the function returns if the lock is already taken, which avoids the
aforementioned crash without stranding the Objective-C runtime lock.
Because LLDB gets to allocate the underlying memory we also avoid
stranding the malloc lock.

rdar://89373233

Differential revision: https://reviews.llvm.org/D127252