LLDB crash

I am seeing a similar crash in our project when using the iOS 17 or 18 simulator. We are getting Symbol not found: _NSUserActivityTypeBrowsingWeb. Running the iOS 26 simulator is fine and running our project in Xcode 16 is also still fine.

@DTS Engineer I started checking the crash again and from what I see all issues are related to specific device - AppleTV6,2. This device seems to be the first apple tv device that supports 4K. No crashes for newer devices so I wonder what could be the difference comparing to the newer generation of apple tv's. Does this specific device have some more strict limitations about memory usage comparing to second generation? Unfortunately that's the device that I do not have on my own to check it so maybe that's the reason why I cannot reproduce it.

SceneComplexityValidationSystem Crash on xrOS - Testing Mesh Limits in Industrial Digital Twin PlayToDeviceHostUnity6-2025-07-08-130455.ips Hi everyone, I’m encountering a crash in my Unity app when running on Vision Pro (xrOS 2.5), specifically when adding a large number of mesh objects to the scene. Here’s what I’ve gathered from the crash log—would appreciate any insights or suggestions! Crash Overview Thread: Main thread (com.apple.main-thread) Exception: EXC_CRASH (SIGABRT) (app terminated by system) Trigger: re::ecs2::SceneComplexityValidationSystem::update(re::ecs2::Scene*, re::ecs2::System::UpdateContext) const This suggests the crash occurred during system-level scene complexity validation, likely due to exceeding hardware limits. Key Details Device: RealityDevice14,1 (Vision Pro) OS: xrOS 2.5 Unity Version: 2.3.1 (Beta) Memory Usage: Virtual: ~3.7GB (857.8MB resident, per vmSummary). Possible Causes Scene Complexity Limits: The SceneComplexityValidationSy

So, just to be clear, pas_reallocation_did_fail is a red herring. Look at the backtrace in your third-party crash report: 5 JavaScriptCore … pas_reallocation_did_fail + 195648 6 JavaScriptCore … pas_reallocation_did_fail + 180240 7 JavaScriptCore … pas_reallocation_did_fail + 181376 8 JavaScriptCore … pas_reallocation_did_fail + 180240 9 JavaScriptCore … pas_reallocation_did_fail + 187084 10 JavaScriptCore … pas_reallocation_did_fail + 186032 11 JavaScriptCore … pas_reallocation_did_fail + 187084 12 JavaScriptCore … pas_reallocation_did_fail + 186032 13 JavaScriptCore … pas_reallocation_did_fail + 186032 14 JavaScriptCore … pas_reallocation_did_fail + 180240 15 JavaScriptCore … pas_reallocation_did_fail + 186032 16 JavaScriptCore … pas_reallocation_did_fail + 187084 17 JavaScriptCore … pas_reallocation_did_fail + 7297626328 All of the symbol offsets are large, and one is ginormous. It’s very unlikely that pas_reallocation_did_fail is 7 GiB long! That indicates that your third-party crash rep

I can confirm that this crash is fixed in beta 3.

Probably, no one here will know for sure, but your guess is sound. I would put a launch screen in now and just be done with it. They're easy to do, so there's no real reason not to, and it means your app won't crash. Win-win!

After learning that Endpoint Security (ES) clients must be packaged in an “app-like” structure to use a provisioning profile, I followed Apple’s technical note and Quinn’s advice: Steps Taken App Bundle Creation Created a bundle named FidelisEvents.app, with standard macOS .app layout. Placed my universal Mach-O (x86_64/arm64) binary at FidelisEvents.app/Contents/MacOS/fidelisevents. Added an Info.plist at FidelisEvents.app/Contents/Info.plist with the correct CFBundleIdentifier and metadata (matching the provisioning profile/App ID). Provisioning Profile Embedded the provisioning profile at FidelisEvents.app/Contents/embedded.provisionprofile. Profile type: Developer ID Application for macOS. App ID and team identifier match the bundle and entitlements. Profile entitlements explicitly include: com.apple.application-identifier com.apple.developer.team-identifier com.apple.developer.endpoint-security.client Confirmed by extracting and inspecting the embedded profile. Entitlements Used an entitlements plist at

As described, what I do was very simple, so I did not provide much more detail. Apart from mprotect and mlock, no low-level stuff or techniques were used. If you need any other details, you can read the demo code. #import MallocGuardManager.h #include #import UIKit/UIKit.h @interface MallocGuardManager() { uintptr_t *_buffers; int _bufferCount; int _cachePageSize; BOOL _use_mlock; } @property (nonatomic, strong) NSMutableArray *container; @property (nonatomic, strong) NSString *templateSource; @property (nonatomic, strong) dispatch_queue_t queue; @property (nonatomic, assign) BOOL started; @property (nonatomic, assign) BOOL executing; @property (nonatomic, assign) BOOL scheduled; @end @implementation MallocGuardManager + (instancetype)sharedInstance{ static id instance = nil; static dispatch_once_t onceToken; dispatch_once(&onceToken, ^{ instance = [[MallocGuardManager alloc] init]; }); return instance; } - (instancetype)init{ self = [super init]; if (self) { _container = [[NSMutableArray alloc] init]; _

Same issue here. It looks like the crash happens specifically when a UIToolbar is added via a .xib file. If you add the toolbar programmatically instead, the crash doesn't occur. So as a temporary workaround, I'd recommend creating the UIToolbar in code rather than using Interface Builder.