“LLDB crash”

I am facing a persistent issue with an Endpoint Security (ES) extension that is crashing only when processing the ES_EVENT_TYPE_AUTH_OPEN event. Other event types, including ES_EVENT_TYPE_NOTIFY_OPEN and ES_EVENT_TYPE_NOTIFY_MMAP, work without any problems. func startMonitoring() { guard !isMonitoring else { return } let result = es_new_client(&gClient) { (client, message) in guard message.pointee.action_type == ES_ACTION_TYPE_AUTH else { return } let pid = audit_token_to_pid(message.pointee.process.pointee.audit_token) if pid == gSelfPID { es_respond_flags_result(client, message, 0x7FFFFFFF, true) var token = message.pointee.process.pointee.audit_token es_mute_process(client, &token) return } guard message.pointee.event_type == ES_EVENT_TYPE_AUTH_OPEN else { es_respond_auth_result(client, message, ES_AUTH_RESULT_ALLOW, true) return } let pathData = message.pointee.event.open.file.pointee.path guard let pathPtr = pathData.data else { es_respond_flags_result(client, message, 0x7FFFFFFF, true)

crash stack: Crashed: com.apple.main-thread 0 libsystem_pthread.dylib 0x90c thread_chkstk_darwin + 60 1 libsystem_pthread.dylib 0x90c ___chkstk_darwin + 60 2 CoreAutoLayout 0x14c4 -[NSISEngine _flushPendingRemovals] + 56 3 CoreAutoLayout 0x2de08 -[NSISEngine _coreReplaceMarker:withMarkerPlusDelta:].cold.1 + 64 4 CoreAutoLayout 0x15d78 -[NSISEngine _coreReplaceMarker:withMarkerPlusDelta:] + 204 5 CoreAutoLayout 0x2ce38 -[NSISEngine constraintDidChangeSuchThatMarker:shouldBeReplacedByMarkerPlusDelta:] + 108 6 CoreAutoLayout 0x15f1c -[NSISEngine tryToChangeConstraintSuchThatMarker:isReplacedByMarkerPlusDelta:undoHandler:] + 100 7 CoreAutoLayout 0x2fdbc -[NSLayoutConstraint _tryToChangeContainerGeometryWithUndoHandler:] + 252 8 CoreAutoLayout 0x3020c -[NSLayoutConstraint _setSymbolicConstant:constant:symbolicConstantMultiplier:] + 452 9 CoreAutoLayout 0x30378 -[NSLayoutConstraint setConstant:] + 84 10 UIKitCore 0x51c3c __74-[UIView(UIConstraintBasedLayout) _autoresizingConstraints_frameDidChange

We're developing an Electron app for MacOS App Store. When updating our app through TestFlight, TestFlight prompts Close This App to Update, and when I click Continue our app would be Terminated for update. Now this is where things go wrong. On MacOS 15 our app seems to be gracefully terminating (We attached it with lldb and it shows that our app returns with 0 when we click Continue) which is fine. However for MacOS 26 though, it seems that TestFlight just directly SIGKILLs our app (indicated by lldb), which means that all of our app's child processes are left orphaned. Even worse, our app is singleton, which means that when the app relaunches it fails, because the leftover child processes from the previously SIGKILLed session is still alive, and even if we want to kill those orphaned child processes we can't because our app is sandboxed thus cannot kill processes outside of the current sandbox. We captured output from log stream (app name redacted): 12-02 22:08:16.477036-0800 0x5452 Defaul

Hi, I am implementing a premium feature in my app where CloudKit syncing is available only for Pro users. The Workflow: Free Users: I initialize the ModelContainer with cloudKitDatabase: .none so their data stays local. Pro Upgrade: When a user purchases a subscription, I restart the container with cloudKitDatabase: .automatic to enable syncing. The Problem: If a user starts as Free (creates local data) and later upgrades to Pro, the app crashes immediately upon launch with the following error: Fatal error: Failed to create ModelContainer: SwiftDataError(_error: SwiftData.SwiftDataError._Error.loadIssueModelContainer, _explanation: nil) It seems that SwiftData fails to load the existing data once the configuration changes to expect a CloudKit-backed store. My Question: Is there a supported way to toggle CloudKit on for an existing local dataset without causing this crash? I want the user's existing local data to start syncing once they pay, but currently, it just crashes. My code: i

I'm working on a multi-process macOS application (based on Chromium/Electron) that uses Mach ports for inter-process communication between the main app and its helper processes. Background I have an MAS build working successfully via TestFlight for internal testing. However, public TestFlight testing requires Apple review, and while waiting for that review, I wanted to provide a directly distributable build for external testers. I attempted to create a Developer ID signed build with App Sandbox enabled, expecting it to behave similarly to the MAS build. The Problem With App Sandbox enabled (com.apple.security.app-sandbox) and identical entitlements, I observe different behavior depending on the signing certificate: Apple Distribution certificate: App launches successfully, mach-register and mach-lookup work Developer ID certificate: App crashes at launch, mach-register is denied by sandbox The Console shows this sandbox violation for the Developer ID build: Sandbox: MyApp(13605) deny(1) mach-register

I have been using Xcode Version 26.1.1 on macOS Tahoe Version 26.1. In VIM mode, whenever I quickly tap d twice, to delete the complete line, most of the time Xcode crashes. Is anyone else facing this issue? Should I move to any older version of Xcode or any other solve for this?

Hi We have an AppleTV app that is used to continuously display information (digital signage). One of our clients reports that their AppleTV returns to the homescreen by morning. While our recommendation is to setup Mobile Device Management to lock the AppleTV into running only our app, not every client will have the IT knowledge to set this up. So we're trying to figure out possible causes for the app getting closed. We've not received any crash reports, nor does the device give any indication the app crashed. The energy saving settings are set to run continuously without sleep. The client is reporting this happens every night, so it seems unlikely to be caused by tvOS updates. Are there other things I could rule out to find the cause of this issue? Any ideas are welcome, thanks!

After upgrading to iOS 18, crashes caused by calling null function pointers have changed their crash signal from SIGEGV to SIGKILL, making it impossible for developers to capture crash stacks using third-party components like KSCrash/PLCrashReporter. Is this a design change in iOS 18's memory protection mechanism? If so, are there any officially recommended crash capture solutions? - (void)MockCrashOnNullFunctionPointer { void (*func)(void) = NULL; func(); } Crash report comparison:

After upgrading to iOS 18, crashes caused by calling null function pointers have changed their crash signal from SIGEVG to SIGKILL, making it impossible for developers to capture crash stacks using third-party components like KSCrash/PLCrashReporter. Is this a design change in iOS 18's memory protection mechanism? If so, are there any officially recommended crash capture solutions? Crash example code: - (void)MockCrashOnNullFunctionPointer { void (*func)(void) = NULL; func(); } Crash report comparison: