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
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
Layout Engine Crash on iOS 26: NSInternalInconsistencyException
Starting with iOS 26 beta, I'm encountering an intermittent crash in production builds related to Auto Layout and background threading. This crash did not occur on iOS 18 or earlier and has become reproducible only on devices running iOS 26 betas. We have already performed a thorough audit of our code: • Verified that all UIKit view hierarchy and layout mutations occur on the main thread. • Re-tested with strict logging—confirmed all remaining layout/constraint/view updates are performed on the main thread. • No third-party UI SDKs are used in the relevant flow. Despite that, the crash still occurs and always from a background thread, during internal UIKit layout commits. Fatal Exception: NSInternalInconsistencyException Modifications to the layout engine must not be performed from a background thread after it has been accessed from the main thread. 0 MyApp 0x7adbc8 FIRCLSProcessRecordAllThreads + 172 1 MyApp 0x7adfd4 FIRCLSProcessRecordAllThreads + 1208 2 MyApp 0x7bc4b4 FIRCLSHandl
Topic: UI Frameworks SubTopic: UIKit Tags:
4
0
460
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)
Topic: Safari & Web SubTopic: General Tags:
1
0
682
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
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
Reply to App Store code signing show "Beta Profile"
I discovered the error when I failed to launch the app in TestFlight. I still continue to submit for App Review and obviously, it got rejected. Attached is the crash report. crashlog-8B515F2C-530E-4779-8C09-2EB4845511E5 1.ips The above steps are my troubleshooting to make sure the app is signed using the Apple Distribution certificate and the correct Provisioning Profile. This issue started after I renewed the expired Apple Distribution certificated. So, I suspect the issue is with the certificate. (I have re-generated at least two times.)
Topic: Code Signing SubTopic: Certificates, Identifiers & Profiles Tags:
Jul ’25
NSInternalInconsistencyException Reason: Modifications to the layout engine must not be performed from a background thread
Hello, We have a Xamarin app in the stores (I know, Xamarin is EOL). We are working on a new version, but do to planning issues, it's not yet ready to be published. We now have a customer who complains that our app is crashing on iOS 26 beta. Our biggest question now is: will it be fixed in the stable release of iOS 26 or will we get a lot of complains around mid September? We currently don't have a device running iOS 26. The crash logs show multiple devices: iPhone 15, iPhone 15 Pro Max and iPhone 16 Pro This is the crash log: Runtime.ThrowNSException (System.IntPtr ns_exception) SIGABRT: Objective-C exception thrown. Name: NSInternalInconsistencyException Reason: Modifications to the layout engine must not be performed from a background thread after it has been accessed from the main thread. Native stack trace: 0 CoreFoundation 0x00000001a2e438dc 44CF748C-19F2-31C4-A0F1-143E32768AF1 + 825564 1 libobjc.A.dylib 0x000000019ffa17a4 objc_exception_throw + 88 2 CoreAutoLayout 0x00000001
Topic: UI Frameworks SubTopic: General
0
0
130
Jul ’25
Reply to Encounter "zsh: trace trap" after updating trust settings for Apple certificates
Thanks for the crash report. This clearly indicates that your app was up and running when it crashed. The backtrace of the crashing thread looks like this: Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libsystem_platform.dylib … sys_icache_invalidate + 40 1 libllvmlite.dylib … llvm::sys::Memory::protectMappedMemory(llvm::sys::MemoryBlock const&, unsigned int) + 356 2 libllvmlite.dylib … LLVMPY_TryAllocateExecutableMemory + 92 3 libffi.dylib … ffi_call_SYSV + 80 4 libffi.dylib … ffi_call_int + 1220 5 _ctypes.cpython-312-darwin.so … _ctypes_callproc + 1384 6 _ctypes.cpython-312-darwin.so … PyCFuncPtr_call + 212 7 Python … _PyObject_Call + 164 That suggests you’re hitting a hardened runtime incompatibility. See Resolving Hardened Runtime Incompatibilities. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com
Topic: Code Signing SubTopic: General Tags:
Jul ’25