Search results for

LLDB crash

30,300 results found

Post

Replies

Boosts

Views

Activity

Reply to System Panic with IOUserSCSIParallelInterfaceController during Dispatch Queue Configuration
Hi Kevin, Thank you for your feedback and the feedback from the engineering team. We have integrated all suggestions from your forum posts (ID: 875288022, 875587022) and the Bug Report, and have conducted a full round of testing. Below is our current status. We now perform a memset on SCSIUserParallelResponse in the ISR and correctly populate the version, fControllerTaskIdentifier, and fBytesTransferred fields. The ISR now differentiates between Bundled/Legacy modes, calling BundledParallelTaskCompletion (without release()) and ParallelTaskCompletion (with release()) accordingly. The aforementioned fixes have resolved all 0x92000006 Panics and DEXT Corpse crashes. Unplugging the hardware or deactivating the DEXT while the driver is in a hung state no longer triggers a panic. We are in a logical deadlock. The kernel dispatches a probe command before UserCreateTargetForID returns, and both of our methods for handling this command result in a permanent hang of the registration process: Scenario A (Repor
Topic: App & System Services SubTopic: Drivers Tags:
1w
iOS 26 WKWebView STScreenTimeConfigurationObserver KVO Crash
Fatal Exception: NSInternalInconsistencyException Cannot remove an observer for the key path configuration.enforcesChildRestrictions from , most likely because the value for the key configuration has changed without an appropriate KVO notification being sent. Check the KVO-compliance of the STScreenTimeConfigurationObserver [class.] I noticed that on iOS 26, WKWebView registers STScreenTimeConfigurationObserver, Is this an iOS 26 system issue? What should I do?
Topic: UI Frameworks SubTopic: UIKit Tags:
15
0
1.3k
1w
UIActivityViewController not vertically scrollable when sharing CSV on specific device (Save option unreachable)
Platform UIKit iOS UIActivityViewController Environment Device (issue reported): iPhone 16 iOS Version: 26.2 App Type: UIKit / Swift (standard modal presentation of UIActivityViewController) Summary When presenting UIActivityViewController to share a CSV file, the share sheet does not allow vertical scrolling, making lower actions (including Save to Files) unreachable. The same flow works correctly when sharing a PDF, and the issue cannot be reproduced on other test devices. Steps to Reproduce Launch the app and log in Navigate to More → Reports Tap Export Report Choose Export Report (CSV) Observe the share sheet Expected Result The user should be able to vertically scroll the share sheet All share actions (including Save to Files) should be reachable Actual Result Share sheet opens but vertical scrolling is disabled Lower options (including Save to Files) are not reachable No crash or console errors
2
0
205
1w
Crash when trying to get originatingRecipient
According to the documentation (https://developer.apple.com/documentation/avfoundation/avcontentkeyrequest/originatingrecipient?changes=_3&language=objc), starting with ios 18.4, I can get AVContentKeyRecipient from AVContentKeyRequest. But when I try to get it, I get a crash. What could be the issue? I want to note that I add the asset to the AVContentKeySession using the addContentKeyRecipient method (https://developer.apple.com/documentation/avfoundation/avcontentkeysession/addcontentkeyrecipient(_:)?changes=_3&language=objc).
1
0
137
1w
Reply to Reproducible EXC_BAD_ACCESS in NEDNSProxyProvider when using async/await variants of NEAppProxyUDPFlow
[quote='875671022, DTS Engineer, /thread/815033?answerId=875671022#875671022'] Given that you can reproduce this so easily, I recommend that you file a bug about it now. When doing that: Make sure to enable additional VPN logging, per the VPN (Network Extension) instructions on our Bug Reporting > Profiles and Logs page. After reproducing the problem, grab a sysdiagnose and attach it to your bug report. Once you’re done, post your bug number here. My plan is then to grab the crash report from your sysdiagnose log and dig a bit deeper. [/quote] Sounds good, thank you! Filed report: FB21933607 In addition to the sysdiagnose with the VPN logging profile enabled, I also attached a Minimum Failing Example similar to the code sample in the first message.
1w
Reproducible EXC_BAD_ACCESS in NEDNSProxyProvider when using async/await variants of NEAppProxyUDPFlow
Description I am seeing a consistent crash in a NEDNSProxyProvider on iOS when migrating from completion handlers to the new Swift Concurrency async/await variants of readDatagrams() and writeDatagrams() on NEAppProxyUDPFlow. The crash occurs inside the Swift Concurrency runtime during task resumption. Specifically, it seems the Task attempts to return to the flow’s internal serial executor (NEFlow queue) after a suspension point, but fails if the flow was invalidated or deallocated by the kernel while the task was suspended. Error Signature Thread 4: EXC_BAD_ACCESS (code=1, address=0x28) Thread 4 Queue : NEFlow queue (serial) #0 0x000000018fe919cc in swift::AsyncTask::flagAsAndEnqueueOnExecutor () #9 0x00000001ee25c3b8 in _pthread_wqthread () Steps The crash is highly timing-dependent. To reproduce it reliably: Use an iOS device with Developer Settings enabled. Go to Developer > Network Link Conditioner -> High Latency DNS. Intercept a DNS query and perform a DoH (DNS-over-HT
4
0
282
1w
Reply to app crashes
launch failed, RBSProcessExitContext voluntary I assume that you've discovered this message in the system log. Before going further, double check that it pertains to your app's process so that you don't go chasing down something that doesn't pertain to your app. Now, assuming that you've confirmed that, voluntary is the key word in that message — the most straight-forward explanation for when this happens is that a code path run by your app chose to call exit, ending your app’s process gracefully. This isn’t a crash, so there is no crash report that would backtrace right to the code path that made this call. As a starting point to locating any code paths in your app that call exit() directly, search your app’s entire source code for any calls to the system exit function, including any third-party libraries you use, and see what turns up. I sometimes like to use grep to find issues like these, should they turn up in unexpected corners, or potentially inside pre-compiled libraries that you can
1w
Reply to Reproducible EXC_BAD_ACCESS in NEDNSProxyProvider when using async/await variants of NEAppProxyUDPFlow
OK, cool. Well, not cool, but you know what I mean (-: Given that you can reproduce this so easily, I recommend that you file a bug about it now. When doing that: Make sure to enable additional VPN logging, per the VPN (Network Extension) instructions on our Bug Reporting > Profiles and Logs page. After reproducing the problem, grab a sysdiagnose and attach it to your bug report. Once you’re done, post your bug number here. My plan is then to grab the crash report from your sysdiagnose log and dig a bit deeper. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com
1w
Misusing a Mutex
This is a successor to: https://developer.apple.com/forums/thread/814231 I went into a slightly different direction. I generated more AI slop that use NSLock. Then I had the NSLock usage changed to Mutex usage. Now it crashes with: Task 13: EXC_BREAKPOINT (code=1, subcode=0x18d29326c) On one of the mutex closures. With an extended description: warning: TypeSystemSwiftTypeRef::operator(): had to engage SwiftASTContext fallback for type $s7Combine10PublishersO21LineBreakingPublisherE11SplitAtZeroV12Subscription33_D18F5AAE73662968F407B0A79FBD1F8DLLCy_x_qd__GD I put the class, a Subscription nested in its corresponding Publisher operator, in the given file Subscription.txt
1
0
100
1w
Reply to Misusing a Mutex
You mean that the compiler crashes? If so, that’s probably something best addressed over in Swift Forums > Using Swift. And speaking generally, to improve your chances of getting traction: Be clear about what version of the compiler you’re testing with. Isolate the code into a small test project that reproduces the issue. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com
1w
TUINSRemoteViewController over-release crash in ViewBridge during autorelease pool drain
Summary A crash occurs in ViewBridge framework when a TUINSRemoteViewController object receives -release message after being deallocated. This appears to be a reference counting issue within the ViewBridge framework's internal autorelease pool management. Environment macOS Version: [15.0.0] Application: Custom Qt-based application using Chromium Embedded Framework (xcode version: xcode 15; QT version: 6.5.4 ; CEF version: 138.0.47+g2728d53+chromium-138.0.7204.221) Steps to Reproduce Users are typically using the app normally, but a crash occasionally occurs when they activate and click on the application. This happens infrequently, but it occurs roughly every day. Currently, only a few specific users experience this crash, and it may appear for several consecutive days before disappearing for several days. We cannot reliably reproduce this issue but have collected crash logs from affected users. Crash Analysis Zombie Detection Log: Zombie received -release Dealloc
1
0
163
1w
Reply to Crash/Exception thrown in UITableView initialization stack
Thanks for the post. I love crash files and you came to the correct place as they are better developers here that can help you with a crash. The interesting issue is that is crashing on swift core lib? However will be a great idea you follow this recommendations to post a crash file with all the information that can help them figure it out. Kindly submit a comprehensive crash report, adhering to the guidelines outlined in Posting a Crash Report. https://developer.apple.com/forums/thread/688669 Have you test it with iOS 26.2? In my modest opinion and without code nor much besides the header, the crash you're encountering, suggests that there might be an attempt to access memory that's either invalid or no longer valid. Ensure that the object or table or table items managing the isn't being deallocated prematurely. Any strong reference cycles or unintentional over-release could lead to accessing a dangling pointer. If the table view is being loaded
Topic: UI Frameworks SubTopic: UIKit Tags:
1w
Crash/Exception thrown in UITableView initialization stack
Hello, We are seeing an intermittent crash when initializing a base UITableView with Apple's [initWithFrame:style:] initializer. Crash stack: Role: Foreground OS Version: iOS 26.1 Exception Type: EXC_BREAKPOINT Exception Subtype: KERN_INVALID_ADDRESS EXC_BREAKPOINT: 0 libswiftCore.dylib +0x1358c0 _assertionFailure(_:_:file:line:flags:) 1 UIKitCore +0x1fdca0 0x188c26ca0 (0x188c26b20 + 384) 2 UIKitCore +0x1ffa60 0x188c28a60 (0x188c2890c + 340) 3 UIKitCore +0x2012d0 0x188c2a2d0 (0x188c2a1ec + 228) 4 UIKitCore +0x200f20 0x188c29f20 (0x188c29cac + 628) 5 UIKitCore +0x200428 0x188c29428 (0x188c29384 + 164) 6 UIKitCore +0x18af7f4 -[UITableMetricsAdapter _updateSharedSectionMetricsForListGeometry:] 7 UIKitCore +0x201da8 -[UITableMetricsAdapter tableBackgroundColor] 8 UIKitCore +0x1643a44 ___39-[UITableView _applyAppearanceDefaults]_block_invoke 9 UIKitCore +0x196f3d0 +[UIView _performSystemAppearanceModifications:] 10 UIKitCore +0x1643978 -[UITableView _applyAppearanceDefaults] 11 UIKitCore +0x20285
1
0
88
1w
Apple Silicon M1 crashing with IOPCIFamily based custom KEXT
We have developed an IOPCIFamily based custom KEXT to communicate with Thunderbolt interface storage device. This KEXT is working fine with Apple machines with Intel CPUs in all types of machines (iMac, iMac Pro and MacBooks). We tested this KEXT with Apple Silicon M1 machine where we are observing crash for the very first command we send to the Thunderbolt device. We observed that there is difference in number of bits in Physical Address we use for preparing command PRPs. In Intel machines we get 28-Bit Physical Address whereas in M1 we are getting 36-Bit address used for PRPs. We use inTaskWithPhysicalMask api to allocate memory buffer we use for preparing command PRPs. Below are the options we have used for this: options: kIOMemoryPhysicallyContiguous | kIODirectionInOut capacity: 16kb physicalMask: 0xFFFFF000UL (We want 4kb aligned memory) According to below documentation, we have to use inTaskWithPhysicalMask api to get memory below 4gb. https://developer.apple.com/library/archive/documentation/
6
0
2.6k
1w