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```

Hi folks, I'm trying to debug some broken constraints and I stumbled upon a post on medium that showed how to get the memory address of the view with broken constraints and how to change the bg color for easy debugging. In the post the person show the following code ex [(UIView *)0x7f94ff5b3890 setBackgroundColor: [UIColor greenColor]] It changes the background color of the UIView that has a broken constraint to easily identify it on the app. My goal is to write that code in Swift, since I'm not very familiar with Objective-C and I'd like to know how it looks in Swift. I've got as far as this (fake address for posting purposes) (lldb) ex -l swift -- import Foundation (lldb) ex -l swift -- import UIKit (lldb) ex -l swift -- UnsafeMutableRawPointer(bitPattern: 0x000)?.load(as: UIView.self) (UIView?) $R9 = 0x000 { UIKit.UIResponder = { ObjectiveC.NSObject = {} } } But if I try to print the backgroundColor or any other property, I get this error: 2023-06-29 11:31:22.644347-0300 APP - DBG[...] +[APP.Button frame]: unrecognized selector sent to class 0x000 error: Execution was interrupted, reason: internal ObjC exception breakpoint(-5).. The process has been returned to the state before expression evaluation. Any clues on how to do it or why it is happening? (Also any sessions regarding this kind of debugging is welcome)

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

(lldb) warning: libobjc.A.dylib is being read from process memory. This indicates that LLDB could not find the on-disk shared cache for this device. This will likely reduce debugging performance. iOS Observatory not discovered after 30 seconds. This is taking much longer than expected... process interrupt thread #1, stop reason = signal SIGSTOP frame #0: 0x00000001b0041164 dyld`_dyld_debugger_notification dyld: -> 0x1b0041164 <+0>: ret dylddyld4::Atlas::Bitmap::Bitmap: 0x1b0041168 <+0>: pacibsp 0x1b004116c <+4>: sub sp, sp, #0x50 0x1b0041170 <+8>: stp x24, x23, [sp, #0x10] Target 0: (Runner) stopped. [VERBOSE-2:FlutterObservatoryPublisher.mm(97)] Failed to register observatory port with mDNS with error -65555. [VERBOSE-2:FlutterObservatoryPublisher.mm(99)] On iOS 14+, local network broadcast in apps need to be declared in the app's Info.plist. Debug and profile Flutter apps and modules host VM services on the local network to support debugging features such as hot reload and DevTools. To make your Flutter app or module attachable and debuggable, add a '_dartobservatory._tcp' value to the 'NSBonjourServices' key in your Info.plist for the Debug/Profile configurations. For more information, see https://flutter.dev/docs/development/add-to-app/ios/project-setup#local-network-privacy-permissions

I'm signing an app like this: % codesign --entitlements entitlements.xml --sign "My Cert" AppName % codesign -dv --verbose=4 AppName.app and I was rather hoping that the -dv check would be sufficient for macOS to verify the signature but when I immediately attach lldb and start the process, Finder pops up "Verifying AppName..." and then after some time lldb fails and logs error: Tried to attach to process already being debugged. If I manually wait for the verification popup to disappear then I can attach lldb just fine and run the LLDB script I want to use to extract information from the app. How can I either run the signature verification on the command line or (without a sleep hack) have LLDB wait?

I have Mac OS application with several embedded frameworks. When debugging the application in recent versions of Xcode (comfirmed in 14.2) I am no longer able to inspect opaque C structs defined in a framework when the debugger has stopped in code belonging to the application or a different framework. The application and frameworks are all compiled by me as part of the application workspace, all have debugging enabled, and all are properly generating dSYM files. Does anyone know what might be going on? This is making debugging the framework code very difficult.

[I've already asked this on llvm discourse, no answer yet] Can someone give me a brief intro or point me to documentation that describes how lldb handles the dyld shared cache on macOS? I’m trying to evaluate how to implement the same functionality in Valgrind. Prior to macOS 11 Big Sur Valgrind used DYLD_SHARED_REGION=avoid to force loading the libraries and then to bypass the cache and so to trigger reading the mach-o info to be able to redirect malloc/pthread functions. Without these redirs not much is working correctly.

Hello! I have a baffling situation happening on two different computers in which Xcode (14.2.0, on MacOS 12.6.1) is not being able to attach a debugger. This is happening for completely-fresh-from-scratch apps, both for MacOS and iOS apps. In both cases, the app eventually launches, but Xcode is not able to debug. Following the error message's suggestion, I looked in Console.app and as best as I can tell the proximate cause for the issue is task_for_pid failing; this message is preceded by a number of errors from com.apple.dt.instruments.dtarbiter: Code validity check error: Error Domain=NSOSStatusErrorDomain Code=-67050 "(null)" So my working hypothesis is that something is preventing the application from launching "normally" and so the debugger can't attach as it normally would. Things I have tried: Removing DerivedData, rebuilding Making sure that "Developer Mode" is enabled (via DevToolsSecurity -enable) Ensuring that the resulting binary has the com.apple.security.get-task-allow entitlement, and that "Code Signing Inject Base Entitlements" is set to "Yes" Disabling Gatekeeper system-wide I have also spent a while looking around with codesign and spctl. To my (admittedly non-expert) eye, codesign's output looks about right: [~/Library/Developer/Xcode/DerivedData/DirectoryScratch-cpyzkrtfugtxdugtobmjfbotrxrj] % codesign -d -vvv --entitlements :- Build/Products/Debug/ContentView.app/ Executable=/Users/bedricks/Library/Developer/Xcode/DerivedData/DirectoryScratch-cpyzkrtfugtxdugtobmjfbotrxrj/Build/Products/Debug/ContentView.app/Contents/MacOS/ContentView Identifier=org.bedrick.ContentView Format=app bundle with Mach-O thin (x86_64) CodeDirectory v=20500 size=1091 flags=0x10000(runtime) hashes=23+7 location=embedded Hash type=sha256 size=32 CandidateCDHash sha256=cf6f08586662c29420bf3ab7e673d0614b2c7717 CandidateCDHashFull sha256=cf6f08586662c29420bf3ab7e673d0614b2c771758ec9dce33fa7982fdab2267 Hash choices=sha256 CMSDigest=cf6f08586662c29420bf3ab7e673d0614b2c771758ec9dce33fa7982fdab2267 CMSDigestType=2CDHash=cf6f08586662c29420bf3ab7e673d0614b2c7717 Signature size=4785 Authority=Apple Development: Steven Bedrick (X8L6RQQBAR) Authority=Apple Worldwide Developer Relations Certification Authority Authority=Apple Root CA Signed Time=Jan 9, 2023 at 2:03:55 PM Info.plist entries=19 TeamIdentifier=2E7A87Y536 Runtime Version=13.1.0 Sealed Resources version=2 rules=13 files=0 Internal requirements count=1 size=188 Warning: Specifying ':' in the path is deprecated and will not work in a future release &lt;?xml version="1.0" encoding="UTF-8"?&gt;&lt;!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "https://www.apple.com/DTDs/PropertyList-1.0.dtd"&gt;&lt;plist version="1.0"&gt;&lt;dict&gt;&lt;key&gt;com.apple.security.app-sandbox&lt;/key&gt;&lt;true/&gt;&lt;key&gt;com.apple.security.files.user-selected.read-only&lt;/key&gt;&lt;true/&gt;&lt;key&gt;com.apple.security.get-task-allow&lt;/key&gt;&lt;true/&gt;&lt;/dict&gt;&lt;/plist&gt; If I ask codesign to --verify my .app bundle, this is what I get: [~/Library/Developer/Xcode/DerivedData/DirectoryScratch-cpyzkrtfugtxdugtobmjfbotrxrj] % codesign -vvvv -R="notarized" --check-notarization -vvvv Build/Products/Debug/ContentView.app/ Build/Products/Debug/ContentView.app/: valid on disk Build/Products/Debug/ContentView.app/: satisfies its Designated Requirement test-requirement: code failed to satisfy specified code requirement(s) [~/Library/Developer/Xcode/DerivedData/DirectoryScratch-cpyzkrtfugtxdugtobmjfbotrxrj] % So something does appear to be "up" with the signature/notarization, but I am not sure how to get more information about what the issue might be (turning up the command's verbosity does not give more information). Now, turning to spctl: [~/Library/Developer/Xcode/DerivedData/DirectoryScratch-cpyzkrtfugtxdugtobmjfbotrxrj] % spctl -a -v --raw Build/Products/Debug/ContentView.app/ Build/Products/Debug/ContentView.app/: rejected &lt;?xml version="1.0" encoding="UTF-8"?&gt; &lt;!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"&gt; &lt;plist version="1.0"&gt; &lt;dict&gt; &lt;key&gt;assessment:authority&lt;/key&gt; &lt;dict&gt; &lt;key&gt;assessment:authority:flags&lt;/key&gt; &lt;integer&gt;0&lt;/integer&gt; &lt;/dict&gt; &lt;key&gt;assessment:remote&lt;/key&gt; &lt;true/&gt; &lt;key&gt;assessment:verdict&lt;/key&gt; &lt;false/&gt; &lt;/dict&gt; &lt;/plist&gt; So Gatekeeper is clearly "unhappy" with this file; I had thought that apps launched via Xcode itself were supposed to bypass Gatekeeper, but maybe that's not true? And in any event, I am able to launch the resulting .app file from the Finder without any issues. This is happening on two separate computers, so my next thought was that it might be some kind of issue with my Apple ID? But on a third computer my same Apple ID works just fine for signing and running apps for local development. As best as I can tell I've got them all configured the same way in terms of which certificate/team they are using, etc. though it is certainly possible that I messed that up somehow. They're all running the same version of Xcode and MacOS. One (possibly relevant) difference is that the two non-working machines are managed by my work's IT department, and my user there is part of an ActiveDirectory profile of some kind. The working machine is my own personal laptop. All three machines have Gatekeeper enabled (I tried turning it off system-wide and it did not fix it), and on all three machines my user is part of the "admin" and "_developer" groups, at least according to the groups command. I don't know what-all sort of remote management / security software they may have installed, is it possible that something along those lines could globally prevent task_for_pid attachment? Any thoughts, advice, debugging ideas, magical shell invocations, etc. would be most welcome. Thank you!

`   func submitBackgroundTasks() {    // Declared at the "Permitted background task scheduler identifiers" in info.plist    let backgroundAppRefreshTaskSchedulerIdentifier = "com.FeedX.backgroundAlerts"    let timeDelay = 10.0    do {     let backgroundAppRefreshTaskRequest = BGAppRefreshTaskRequest(identifier: backgroundAppRefreshTaskSchedulerIdentifier)     backgroundAppRefreshTaskRequest.earliestBeginDate = Date(timeIntervalSinceNow: timeDelay)     try BGTaskScheduler.shared.submit(backgroundAppRefreshTaskRequest)     print("Submitted task request")    } catch {     print("Failed to submit BGTask")    }   } I am able to submit the task and hit the breakpoint but in the LLDB i try to simulate the task using the command e -l objc -- (void)[[BGTaskScheduler sharedScheduler] _simulateExpirationForTaskWithIdentifier:@"com.FeedX.backgroundAlerts"] But i get the following error : error: Error [IRForTarget]: Rewriting an Objective-C constant string requires CFStringCreateWithBytes Any idea on how to solve this or run the task using a different way? Thanks.

I'm getting the error "Cannot create Swift scratch context (couldn't create a ClangImporter)" when running a Swift project in XCode 12.3 on Catalina when I try to use the debugger. There is a resolution of this problem described at https://forums.raywenderlich.com/t/entering-debugger-in-swift-project-couldnt-create-a-clangimporter/130829 but I don't understand the fix of "removing zsh customisations in dotfiles". Can anyone explain what the files to change are and how they have to be changed? (I'm new to Mac development)

When I run my app from Xcode 12b1 and hit a break point, LLDB says "Cannot create Swift scratch context (couldn't load the Swift stdlib)" and any subsequent commands like "po" seem to do nothing. Who can I fix this?

It's start recently and I can't figure out the reason of this. For some reason debugger does not highlight the line with the error when I'm using simulator, it's just crash with the same error in lldb for all cases of error: libc+abi: terminating with uncaught exception of type NSException Message from debugger: Terminated due to signal 6 and crush log, it can be different for different cases. But if I will use device for debugging on the same errors it will highlight error in code and I can debug normally. Recently I install Xcode 14 and everything was okay with debugging using simulator, but now for some reason it broke.

When I set breakpoints on os_log statements like below: os_log_debug(OS_LOG_DEFAULT, "hi"); //&lt;--break point RIGHT on this line…. I have to click the "Continue Program Execution" button three times to actually continue program execution. At first I thought my method was being called multiple times unexpectedly but it’s not. I just have to keep hitting the continue program execution button. I’m not hitting “Step over” or “step into”. I’m hitting the “Continue Program Execution” button. FB9792745