Hello, I have tried to create a thread with thread_create_running API. It works but i would like to suspend this thread. I can call thread_suspend, but my thread has already been start before i call this API. Is there a way to create a thread without running it automaticaly. Thanks

Hello, My purpose is to understand how macOS works. Here is what i've done: I have wrote a c program on a M1 CPU with this lines: printf("Before breakpoint\n"); asm volatile("brk #0"); printf("After breakpoint\n"); When i run this program with lldb, a breakpoint is hit on the second line. So i suppose lldb is writing a "brk #0" instruction when we put a breakpoint manually. I can't continue to next line with lldb "c" command. PC stays on the brk instruction. I need to manually set PC to next instruction in lldb. Now, what i want to do is to create my own debugger. (I want to understand how lldb works). I have managed to ptrace the target program and i was able to catch an event with waitpid when "brk #0" is hit. But i don't know how i can increase PC value and continue execution because i can't do this on Silicon CPU: ptrace(PTRACE_GETREGS, child_pid, NULL, &regs); ptrace(PTRACE_SETREGS, child_pid, NULL, &regs); kill(child_pid, SIGCONT); So my question is: How does lldb managed to change ARM64 registers of a remote process ? Thanks

Hello, I am facing an issue when debugging cpp code through the XCode after updating to XCode 15.0. During debugging, in a variables watch view, it is shown for the collections (let's take std::vector as an example) that its size is 0 even if it is not. If I add it as an expression to watch, it is fine. Also if I print it in lldb console, it is also fine. Any thoughts on this?

I don't know when this started but it's basically brought my development to a standstill. I know it worked fine in macOS 13.2.1, though I didn't try Xcode 14.3 RC 2 in 13.2.1. Basically, Xcode 14.3 RC 2 (14E222b) and also Xcode 14.2 (14C18) (which had been stable up till now) are both unable to launch the app in debug mode. As soon as the launched/debugged app finally starts, the following is printed to Xcode's console: Message from debugger: The LLDB RPC server has crashed. You may need to manually terminate your process. The crash log is located in ~/Library/Logs/DiagnosticReports and has a prefix 'lldb-rpc-server'. Please file a bug and attach the most recent crash log. The crash log is always the same. The full log is at https://gist.github.com/NSGod/5e194900bd6f5a9ac9328b936a26037e. There seems to be an infinite loop in thread 6: Thread 6 Crashed:: <lldb.process.internal-state(pid=30877)> 0 LLDB 0x12030cfb4 ParseTrieEntries(....) + 20 1 LLDB 0x12030d653 ParseTrieEntries(....) + 1715 After I initially encountered this issue in Xcode 14.3 RC 2 (14E222b) with my business project, I tried creating a new Cocoa app using Xibs and Objective-C and still encountered the problem in that project. I've cleaned out the build folders, etc. but that made no difference. I opened both my business project and a new project in Xcode 14.2 (14C18) but saw no difference (it still crashes). I also tried in a new user account using both versions of Xcode but they both crash. Could having Python 3.10 and 3.11 installed through MacPorts anything to do with it (I noticed Python 3.9 in the binary images, but I'm not sure). Any ideas?

How are debug maps saved in Mach-O files? I'm trying to essentially recreate the output of dsymutil -dump-debug-map.

I’m trying to use the allocated variables given after p self ($R1 for instance) but after resuming the process and then pausing it again, I cannot access to $R1. (lldb) p self (Signals.MainContainerViewController) $R1 = 0x000000012ba19dc0 { ... (lldb) po $R1 <Signals.MainContainerViewController: 0x12ba19dc0> (lldb) c Process 88944 resuming (lldb) expression -O -l swift -- $R1 warning: Module "/usr/lib/system/libsystem_kernel.dylib" uses triple "arm64-apple-macosx13.4.0", which is not compatible with the target triple "arm64-apple-ios16.0.0-simulator". Enabling per-module Swift scratch context. error: expression failed to parse: error: <EXPR>:3:1: error: cannot find '$R1' in scope $R1 ^~~ (lldb) Does someone have an idea? macOS: 13.4.1 (22F82) Xcode Version 14.3.1

We are running into an issue where breakpoints are not resolving on Xcode 14 (The same break points on Xcode 13.4.1 are working fine). They change to an outline when we run our app I have tried all the usual fixes Cleaned the build Cleaned Derived data Restarted Xcode Restarted the machine Re-cloned the repo to see if starting fresh helps I have also tried Removing all symbol stripping Ensuring the DSYM is getting generated and is loaded in the debugger Removing all optimization options Tried the Xcode 14.1 beta What's really strange is the break points will work occasionally and will work for a few runs and then stop working again. Does anyone have any suggestions?

In some particular situation, Xcode debugger or lldb cli cannot correctly extract some value that returned by a async throw function and handled by guard let try?. Here is the minimum example: import Dispatch func test() async throws -> [Int] {   return [369] } let group = DispatchGroup() group.enter() let task = Task {   guard let res = try? await test() else { return }   print(res)   group.leave() } group.wait() If added a break point at print(res), the debugger cannot show the value of res. Due to forum limitation, I cannot paste a screenshot here... if use p res or po res at lldb cli, it shows: (lldb) p res error: expression failed to parse: error: <EXPR>:3:1: error: cannot find 'res' in scope res ^~~ (lldb) po res error: expression failed to parse: error: <EXPR>:3:1: error: cannot find 'res' in scope res ^~~ If test() returns a dict, or a costom struct, the issue retains. But if returned a trivial value like Int, it acts normally. Also, if remove the guard statement, make res a optional value(use let res = try? await test()), debugger can extract the value. Above results are compiled and run in this environment: Swift 5.6.1 Xcode 13.4.1 (13F100) lldb-1316.0.9.46 macOS 12.4 x86_64 arch

I'm trying to attach with lldb to a x64 process running under Rosetta, attachment itself succeeded but lldb is unable to load target neither it's modules. And getting this output: (lldb) process attach --pid 20586 Process 20586 stopped * thread #1, stop reason = signal SIGSTOP frame #0: 0x00007ff813a1d1ee -> 0x7ff813a1d1ee: jae 0x7ff813a1d1f8 0x7ff813a1d1f0: movq %rax, %rdi 0x7ff813a1d1f3: jmp 0x7ff813a18cdb 0x7ff813a1d1f8: retq Target 0: (No executable module.) stopped. Architecture set to: x86_64-apple-macosx-. (lldb) target modules list error: the target has no associated executable images A few weeks ago I had the same problem, but some combination of actions like rebuilding deleting and redownloading binaries and some other unknown magic fixed this behaviour. And today I stumbled upon this problem again, and same actions does not make any effect. Attaching to process works in general (event to processes running under Rosetta), but this specific process I want to debug is causing troubles. This is what successful attachment looks like: (lldb) process attach --pid 20576 warning: libobjc.A.dylib is being read from process memory. This indicates that LLDB could not read from the host's in-memory shared cache. This will likely reduce debugging performance. Process 20576 stopped * thread #1, name = 'CrRendererMain', queue = 'com.apple.main-thread', stop reason = signal SIGSTOP frame #0: 0x00007ff813a185b2 libsystem_kernel.dylib`mach_msg2_trap + 10 libsystem_kernel.dylib`mach_msg2_trap: -> 0x7ff813a185b2 <+10>: retq 0x7ff813a185b3 <+11>: nop libsystem_kernel.dylib`macx_swapon: 0x7ff813a185b4 <+0>: movq %rcx, %r10 0x7ff813a185b7 <+3>: movl $0x1000030, %eax ; imm = 0x1000030 Target 0: (Electron Helper (Renderer)) stopped. Executable module set to "/Users/mb/work/positron/node_modules/electron/dist/Electron.app/Contents/Frameworks/Electron Helper (Renderer).app/Contents/MacOS/Electron Helper (Renderer)". Architecture set to: x86_64-apple-macosx-. To give a bit more context my MacOS version is 13.14.1 on MacBook Pro with M2 chip.

Why did I get an error in playground in debug window for this code? print("// MARK: - Start execable code here...") do { let store = CNContactStore() if try await store.requestAccess(for: .contacts) { // Do something with Contacts. let phoneNumber = CNPhoneNumber(stringValue: "903-276-1046") let predicateForContactsMatchingPhoneNumber = CNContact.predicateForContacts(matching: phoneNumber) let contactFetchRequest = CNContactFetchRequest(keysToFetch: thoroughKeysToCompare) contactFetchRequest.predicate = predicateForContactsMatchingPhoneNumber contactFetchRequest.unifyResults = true var contactOfMe: CNContact! = nil try! store.enumerateContacts(with: contactFetchRequest) { contact, stop in contactOfMe = contact stop.pointee = true } let contact = Contact(cnContact: contactOfMe) for property in contact.enumerated() { print("- \(property)") } } else { // Handle if Contacts access is denied. fatalError() } } catch { // Handle any error. print("error requesting access: \(error.localizedDescription)") } Debug window: // MARK: - Start execable code here... Playground execution failed: error: Execution was interrupted, reason: shared-library-event. The process has been left at the point where it was interrupted, use "thread return -x" to return to the state before expression evaluation. * thread #1, queue = 'com.apple.main-thread' frame #0: 0x00007ff80002f931 libobjc.A.dylib`_mapStrHash(_NXMapTable*, void const*) + 73 frame #1: 0x00007ff80002fc7f libobjc.A.dylib`_NXMapMember(_NXMapTable*, void const*, void**) + 35 frame #2: 0x00007ff80003b7ae libobjc.A.dylib`getProtocol(char const*) + 41 frame #3: 0x00007ff8000428e6 libobjc.A.dylib`class_conformsToProtocol + 337 frame #4: 0x00007ff80004ab4e libobjc.A.dylib`-[NSObject conformsToProtocol:] + 47 frame #5: 0x0000000109c27951 UIKitCore`_UIFocusItemContainerIsScrollableContainer + 74 frame #6: 0x0000000109c28e38 UIKitCore`-[_UIFocusEnvironmentContainerTuple initWithOwningEnvironment:itemContainer:] + 194 frame #7: 0x0000000109c28fed UIKitCore`+[_UIFocusEnvironmentContainerTuple tupleWithOwningEnvironment:itemContainer:] + 70 frame #8: 0x0000000109c4f41e UIKitCore`_UIFocusRegionContainerFromEnvironmentAndContainer + 44 frame #9: 0x0000000109c27ed3 UIKitCore`_UIFocusItemContainerAddChildItemsInContextWithArguments + 1162 frame #10: 0x000000010a99c439 UIKitCore`-[UIView _searchForFocusRegionsInContext:] + 962 frame #11: 0x0000000109c6b37f UIKitCore`-[_UIFocusMapSnapshot addRegionsInContainer:] + 4583 frame #12: 0x0000000109c69740 UIKitCore`-[_UIFocusMapSnapshot _capture] + 456 frame #13: 0x0000000109c67fc5 UIKitCore`-[_UIFocusMapSnapshot _initWithSnapshotter:mapArea:searchArea:] + 628 frame #14: 0x0000000109c6cce2 UIKitCore`-[_UIFocusMapSnapshotter captureSnapshot] + 227 frame #15: 0x0000000109c5f450 UIKitCore`-[_UIFocusMap _inferredDefaultFocusItemInEnvironment:] + 147 frame #16: 0x0000000109c2b1cf UIKitCore`-[_UIFocusEnvironmentPreferenceEnumerationContext _inferPreferencesForEnvironment:] + 157 frame #17: 0x0000000109c2abbc UIKitCore`-[_UIFocusEnvironmentPreferenceEnumerationContext _resolvePreferredFocusEnvironments] + 118 frame #18: 0x0000000109c2ab12 UIKitCore`-[_UIFocusEnvironmentPreferenceEnumerationContext prefersNothingFocused] + 31 frame #19: 0x0000000109c2beeb UIKitCore`_enumeratePreferredFocusEnvironments + 198 frame #20: 0x0000000109c2c061 UIKitCore`_enumeratePreferredFocusEnvironments + 572 frame #21: 0x0000000109c2c061 UIKitCore`_enumeratePreferredFocusEnvironments + 572 frame #22: 0x0000000109c2c061 UIKitCore`_enumeratePreferredFocusEnvironments + 572 frame #23: 0x0000000109c2bd11 UIKitCore`-[_UIFocusEnvironmentPreferenceEnumerator enumeratePreferencesForEnvironment:usingBlock:] + 230 frame #24: 0x0000000109c2c747 UIKitCore`-[_UIDeepestPreferredEnvironmentSearch deepestPreferredFocusableItemForEnvironment:withRequest:] + 817 frame #25: 0x0000000109c95837 UIKitCore`-[UIFocusUpdateContext _updateDestinationItemIfNeeded] + 265 frame #26: 0x0000000109c95627 UIKitCore`-[UIFocusUpdateContext _destinationItemInfo] + 22 frame #27: 0x0000000109c95535 UIKitCore`-[UIFocusUpdateContext nextFocusedItem] + 24 frame #28: 0x0000000109c71ea6 UIKitCore`-[UIFocusSystem updateFocusIfNeeded] + 1347 frame #29: 0x0000000109c7608c UIKitCore`__43-[UIFocusSystem _updateFocusUpdateThrottle]_block_invoke + 34 frame #30: 0x000000010a94b971 UIKitCore`-[_UIAfterCACommitBlock run] + 57 frame #31: 0x000000010a94be71 UIKitCore`-[_UIAfterCACommitQueue flush] + 191 frame #32: 0x000000010a3926eb UIKitCore`_runAfterCACommitDeferredBlocks + 782 frame #33: 0x000000010a380fa2 UIKitCore`_cleanUpAfterCAFlushAndRunDeferredBlocks + 96 frame #34: 0x000000010a3b6be1 UIKitCore`_afterCACommitHandler + 58 frame #35: 0x00007ff8003b1c12 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 23 frame #36: 0x00007ff8003ac57f CoreFoundation`__CFRunLoopDoObservers + 515 frame #37: 0x00007ff8003acaa2 CoreFoundation`__CFRunLoopRun + 1121 frame #38: 0x00007ff8003ac264 CoreFoundation`CFRunLoopRunSpecific + 560 frame #39: 0x00007ff8003ad234 CoreFoundation`CFRunLoopRun + 40 frame #40: 0x00007ff83755a4e3 libswift_Concurrency.dylib`swift_task_asyncMainDrainQueueImpl() + 35 frame #41: 0x00007ff83755a4b4 libswift_Concurrency.dylib`swift_task_asyncMainDrainQueue + 52 frame #42: 0x00000001015d409f $__lldb_expr32`main at <unknown>:0 frame #43: 0x0000000100e25560 EnumeratedContactsCNContact`linkResources + 256 frame #44: 0x00007ff8003b2986 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__ + 12 frame #45: 0x00007ff8003b2148 CoreFoundation`__CFRunLoopDoBlocks + 399 frame #46: 0x00007ff8003ace09 CoreFoundation`__CFRunLoopRun + 1992 frame #47: 0x00007ff8003ac264 CoreFoundation`CFRunLoopRunSpecific + 560 frame #48: 0x00007ff809b4024e GraphicsServices`GSEventRunModal + 139 frame #49: 0x000000010a3827bf UIKitCore`-[UIApplication _run] + 994 frame #50: 0x000000010a3875de UIKitCore`UIApplicationMain + 123 * frame #51: 0x0000000100e256c5 EnumeratedContactsCNContact`main + 357 frame #52: 0x0000000100fbb384 dyld_sim`start_sim + 10 frame #53: 0x000000010943341f dyld`start + 1903```

Env: Monterey 12.6.5, Xcode 14.0.1 Recent update for xcode. Straight forward declaration of bitset, but a large one. std::bitset<1048567> bs ; Running code in xcode, suddenly started getting lldb notice "Message from debugger: The LLDB RPC server has exited unexpectedly. You may need to manually terminate your process. Please file a bug if you have reproducible steps." upon entering the function itself, not when executing the bitset declaration line. Moved the declaration to main, and still lldb notice. Then noticed bitset size in debugger dialog is 256 (see snippet image), although the bitset's "real" size is as declared (debugger shows real size in parentheses, but only show first 256 bits). Checked vector, it is show and represents in full. Duplicated on Ventura 13.3.1, Xcode 14.2. Suspect the LLDB issue was from changing bitset size to pow(2,64) before, which compiles, but generates "thread EXC_BADACCESS ..." error/warning. Two issues: first, why only display first 256 bits of a bitset in debugger? And if there is a logical reason, then change the description for the hard-set 256 size when n >=256 from "size=256" to "view size=256" With the lldb error, I thought there was an error that did not exist, notably compiler was now changing my declared size to 256 for any size n > 256. Second, the "thread EXC_BADACCESS..." error when bitset size is too large should be reported by compiler as max size exceeded, after all, the bitset size n declared has to be a const and the compiler knows both n and the max bitset size_t N...the error reported is better than nothing, but not the most meaningful.

The .NET Runtime has shipped an lldb extension that looks to extend LLDB functionality to be able to reason about .NET managed code. This has been working for a long time, but now it fails to load with the error error: this file does not represent a loadable dylib. Loading works if I use a self-compiled version of LLDB. I can't really debug XCode's LLDB, but there are some logs that seemed to hint it was signing checks failing for library validation, but neither Developer nor Application signing would satisfy these. LLDB resides within the XCode bundle at /Applications/Xcode.app/Contents/Developer/usr/bin/lldb. codesign confirms that the bundle enforces library validation. Is there any way to confirm this is the issue? It looks like: Library Validation failed: Rejecting '/*/libsosplugin.dylib' (Team ID: none, platform: no) for process 'lldb(77691)' (Team ID: none, platform: yes), reason: mapped file has no Team ID and is not a platform binary (signed with custom identity or adhoc?) and Library Validation failed: Rejecting '/*/libsosplugin.dylib' (Team ID: UBF8T346G9, platform: no) for process 'lldb(77691)' (Team ID: none, platform: yes), reason: mapping process is a platform binary, but mapped file is not If that's the issue, what's the suggested way forward to have loadable lldb plugins? If not, what's the recommended way to diagnose this? lldb logging is verbose, but doesn't provide any information around this.

I want to do source level debugging of an external environment using Xcode's graphical debugger. I have an External Build System project with local source files that builds libraries/executables (not macOS or iOS) and creates their dSYM symbol files (also stored locally). I have a script that I can run from Xcode that starts the library/executables (in an external environment), and gets their slide addresses so their symbols can be loaded into lldb. The script also returns a gdb-remote url that I can use with lldb to begin debugging. Is there a way for Xcode to use the lldb info gathered by my script to start its graphical debugger? If this feature doesn't exist, then I see two simple ways that this feature could be implemented: a) In the Run Action, there's a Run Script action in the Pre-actions to start the remote environment and gather the debug info to create a lldb script that has the gdb-remote command, and commands to add the target modules, and to load the target modules with their slide values. All of that I've already implemented. The Run Action can then have an option to launch lldb with the generated lldb source script. b) The Run Script action in the Pre-actions of the Run Action that sets up the external environment and gathers the debug info can launch lldb itself with the generated lldb source script. The Run Action can have an option to watch the terminal output for an lldb prompt and then take over when the prompt appears.

Hi, I have error messages when I try to print some values in debug like "po varname" or "po expression" I have messages: error: expression failed to parse: error: Couldn't realize type of self. I use Xcode without rosetta, 13.3 I tried to clear derived data and clean project, it helps but after relaunch Xcode I have the same problem again