Search results for

LLDB crash

29,559 results found

Post

Replies

Boosts

Views

Activity

Reply to Layout Engine Crash on iOS 26: NSInternalInconsistencyException
[UPDATE] I’ve identified one of the triggers for the crash. The crash occurs immediately after calling becomeFirstResponder() on a UITextField (or similar view) that is fully added to the view hierarchy and visible on screen. This call is made from the main thread. In case of SwiftUI, the crash happens if using @FocusState: @FocusState private var textFieldFocused: Bool TextField(..., text: $text) .focused($textFieldFocused) .onAppear { textFieldFocused = viewModel.shouldFocusWhenAppear } The console log include: Unsupported layout off the main thread for with no associated or ancestor view controller Followed by a crash: NSInternalInconsistencyException: Modifications to the layout engine must not be performed from a background thread after it has been accessed from the main thread.
Topic: UI Frameworks SubTopic: UIKit Tags:
Jul ’25
iOS 26 WebKit Crash
Thread 0 Crashed: 0 WebKit 0x00000001a1b6bf1c WKMouseDeviceObserver.connectedDeviceCount.setter + 68 (WKMouseDeviceObserver.swift:0) 1 WebKit 0x00000001a1b6bea4 @objc WKMouseDeviceObserver.connectedDeviceCount.setter + 152 2 WebKit 0x00000001a1b6d95c closure #2 in WKMouseDeviceObserver.start() + 80 (WKMouseDeviceObserver.swift:0) 3 WebKit 0x00000001a1b4e3e9 <deduplicated_symbol> + 1 4 WebKit 0x00000001a1b4e139 <deduplicated_symbol> + 1 5 WebKit 0x00000001a1b4e769 <deduplicated_symbol> + 1 6 libswift_Concurrency.dylib 0x0000000196037cdd completeTaskWithClosure(swift::AsyncContext*, swift::SwiftError*) + 1 (Task.cpp:546)
1
0
682
Jul ’25
Reply to iOS 26 WebKit Crash
Hello. Can you provide more information about this crash? Can you provide a small Xcode project and some directions that can be used to reproduce this crash? If so, it's probably worth filing a bug report about it. Bug Reporting: How and Why? has tips on creating your bug report.
Topic: Safari & Web SubTopic: General Tags:
Jul ’25
app crashed _CFRelease.cold.1
In my app, I implemented a screen recording functionality. But there was an unexpected crash. 0 CoreFoundation _CFRelease.cold.1 + 16 1 CoreFoundation ___CFTypeCollectionRelease 2 ReplayKit ___56-[RPScreenRecorder captureHandlerWithSample:timingData:]_block_invoke + 148 3 libdispatch.dylib __dispatch_call_block_and_release + 32 4 libdispatch.dylib __dispatch_client_callout + 16 5 libdispatch.dylib __dispatch_lane_serial_drain + 740 6 libdispatch.dylib __dispatch_lane_invoke + 388 7 libdispatch.dylib __dispatch_root_queue_drain_deferred_wlh + 292 8 libdispatch.dylib __dispatch_workloop_worker_thread + 540 9 libsystem_pthread.dylib __pthread_wqthread + 292
4
0
107
Jul ’25
App crashes on launch due to missing Swift Concurrency symbol
I'm encountering a crash on app launch. The crash is observed in iOS version 17.6 but not in iOS version 18.5. The only new notable thing I added to this app version was migrate to store kit 2. Below is the error message from Xcode: Referenced from: <DCC68597-D1F6-32AA-8635-FB975BD853FE> /private/var/containers/Bundle/Application/6FB3DDE4-6AD5-4778-AD8A-896F99E744E8/callbreak.app/callbreak Expected in: <A0C8B407-0ABF-3C28-A54C-FE8B1D3FA7AC> /usr/lib/swift/libswift_Concurrency.dylib Symbol not found: _$sScIsE4next9isolation7ElementQzSgScA_pSgYi_tYa7FailureQzYKFTu Referenced from: <DCC68597-D1F6-32AA-8635-FB975BD853FE> /private/var/containers/Bundle/Application/6FB3DDE4-6AD5-4778-AD8A-896F99E744E8/callbreak.app/callbreak Expected in: <A0C8B407-0ABF-3C28-A54C-FE8B1D3FA7AC> /usr/lib/swift/libswift_Concurrency.dylib dyld config: DYLD_LIBRARY_PATH=/usr/lib/system/introspection DYLD_INSERT_LIBRARIES=/usr/lib/libLogRedirect.dylib:/usr/lib/libBacktraceRecording.dylib:/usr/lib/
1
0
130
Jul ’25
Reply to webView.configuration.websiteDataStore.proxyConfigurations = [proxyConfiguration] crashes app in ios 18
I have conducted tests on this issue using Xcode versions 16.2, 16.3, and 16.4, along with simulator version 17.5 and later. I found that there are no issues when running the app on actual devices. However, we are encountering problems specifically with simulator version 17.5 and Xcode 16.3, as well as with simulator version 18.4 and Xcode 16.4. The application crashes whenever it attempts to access self.webView.configuration.websiteDataStore.proxyConfigurations. Please prioritise this matter, as it is impacting our CI and CD pipeline.
Topic: Safari & Web SubTopic: General Tags:
Jul ’25
Firebase not initializing in iOS Unreal Engine 5.6 app (using MetaHuman + FirebaseFeatures)
Hi everyone, I'm building a native iOS app using Unreal Engine 5.6 with Firebase for authentication and Firestore. The app uses a MetaHuman avatar and is meant to run as a standalone UE app on iPhone. I'm using this Firebase wrapper: 👉 https://pandoa.github.io/FirebaseFeatures/ I've followed all the steps, including: Adding GoogleService-Info.plist to the Xcode project and ensuring it’s in the correct target Calling FIRApp.configure() in AppDelegate Verifying the plist is bundled correctly However, the app crashes on launch, and Firebase does not initialize properly. Crash log shows: [FirebaseCore][I-COR000005] No app has been configured yet. Setup details: Unreal Engine: 5.6 (source build, macOS) iOS Deployment: 17.5 MetaHuman character packaged correctly and app launches fine without Firebase Has anyone here managed to get Firebase working inside a native Unreal Engine iOS app with this setup? I'd love to hear if there’s something I’m missing — maybe something with initialization timing o
1
0
718
Jul ’25
FRONTBOARD crash App killed while running in the background.
PLATFORM AND VERSION iOS Development environment: Xcode 16.2, macOS 15.5 Run-time configuration: iOS 18 DESCRIPTION OF PROBLEM Our app (a VoIP and messaging app) has been experiencing a crash when running in the background for long periods of time (a couple of days) while receiving calls, and message notifications. If the app is not receiving notifications, we don't get any crashes while it runs in the background. It is worth mentioning that we have several pushes that are background pushes and they could happen depending on the outcome of an incoming call. We have the two pushes: incoming call bye: let the app know that the calling end hanged up the call. incoming call answered: lets the app know that another device (with the same shared number) answered the call (web app, Android). Those pushes are delivered within 30 seconds after the call starts. I assume that since the app was awakened by a VoIP push, those background notification won't count towards the iOS restriction of not getting t
3
0
130
Jul ’25
Reply to FRONTBOARD crash App killed while running in the background.
I think everything is clear to me at this point. I just want to clarify one thing about my report: the incoming call bye and incoming call answered pushes are not PushKit notifications, they are the usual background notifications with the content-available flag set to 1. This is why they were the initial suspects. Let me know if you advise against using these background pushes in this case, even if they aren’t to blame. That's an unusual use for those pushes, but no, there's nothing wrong with using them for that. More specifically, as long as these are standard pushes that are delivered into your app through the standard notification delegates, NOT through PushKit, then they cannot cause the crash you're seeing. You may have reliability issues (because the push simply doesn't reach your app), but you won't crash. Also, just to make sure this was clear, the ONLY thing that can cause this crash: Termination Reason: FRONTBOARD 0xbaadca11 ...is failing to report a CallKit call in respo
Topic: App & System Services SubTopic: General Tags:
Jul ’25
Reply to dyld iteration in signal handlers
Thanks for the response. I've read your post many times over, it's the reference, and it's a great one. That being said, obviously your stance is the right one, but as you sort of mention, some of us don't have a choice of writing a crash reporter because the one supplied to us by the OS is too limited or just doesn't cover everything we need. That being said, I'm curious what you think about using task_info and TASK_DYLD_INFO, and caching that address. That is not signal safe, but after that we're talking lockless access to a mutable list that will only ever grow which is way better than wasting resources caching dyld updates, and is signal safe.
Topic: App & System Services SubTopic: Core OS Tags:
Jul ’25