LLDB crash

I am also able to reproduce a crash using the provided code; however, it does not immediately crash for me; rather, if I select the text then it will crash (with a metal-related error). I'm running MacOS Sequoia (15.5) with XCode Version 26.0 beta 4 (17A5285i).

I see a very similar issue. The swift code has a text editor (NSTextView) and as soon as a scroll bar is added, the app crashes with an error like: [MTLDebugRenderCommandEncoder setRenderPipelineState:]:1616: failed assertion `Set Render Pipeline State Validation For color attachment 0, the texture sample count (1) does not match the renderPipelineState sampleCount (1065353216). and a similar-looking stacktrace involving MTLReportFailureand other drawing-related functions like QuartzCore (draw_shape, array_flush, draw_elements, draw etc). Possibly relevant - this is on an older intel mac with a now-unsupported GPU.

As a quick admin note, the comment feature in our forums doesn't really work very well, so I'd always recommend just posting your reply. These log message from com.apple.FSKit, category default, seem relevant. Looking at our code, I think something went wrong in your probeResource. Breaking down the log messages, these three messages are logged before calling probeResource and validates basic I/O: Successful dynamic cast of resource to bd. Got fd 3 readFirstSectorAndLog reading from 3 got rv 512 error (null) Successful read, first characters 4c4b:6000 This is logged by the reply block we pass to probeResource. The null here indicates that the FSProbeResult you returned was NULL: Returning (null) And this is logged shortly after in the same block, logging the Error probeResource returned: FSModule dev.steve.MFSLives.MFS probe: returned Error Domain=NSPOSIXErrorDomain Code=22 Invalid argument Notably, I don't see any logs from my code, so although it claims that the probe failed, it's not because of my code. So

I had the same crash happening, i managed to fix it. let me explain my use case, maybe it helps someone. I had a local database and a cloud database. The user could choose to migrate from local to cloud. During this process, I sometimes got OPs crash. I had something like this: local = try ModelContainer.local() cloud = try ModelContainer.cloud() try migrate(toCloud: true) try local.erase() //after migration, I erased the local instance. local = try ModelContainer.local() // << the fix // reinitializing the local container fixed the crash.

When building as described above, the helper crashes in such a way (Termination Reason: CODESIGNING 4 Launch Constraint Violation) that suggests I need to apply launch constraints to resolve the problem. I had not previously had launch constraints in my project.

Hi , Were having a similar issue, our company builds a web safari extension for enterprise. before iOS 26 (beta) release we would archive our extension and install to our devices no problem. since iOS 26 (beta) (we also tried in beta 4 23A5297m) the extension would archive perfectly but when installing the extension would just not run. its found in settings under safari extension, but when enabled the extension and open safari it will show error message Ext is no longer available. to rule out all code issues, we built a new project from scratch with a new bundle id, tried to archive with no problem, but when installed in an iphone 16 with iOS 26 BETA (23A5297m) same error ocurs it installs but when opening safari it will give an error message saying extension is no longer available. attached in the google drive link is a zip file of the new project, a zip file with a succesfull build of the ipa file with enterprise distribute, a video of the entire proccess and the error that the iphone gives. also attached a

The property you're referring to (usesClassicLoadingMode) is available on 18.4+ (wouldn't help for my users who are on iOS 17 and early 18) and it's true by default on the shared URLSession which I use throughout the entire app. I don't use any other session, no custom configurations. I just use Task a lot. Yet I still get crash reports from users on 18.6.2. Therefore I think it's safe to say it doesn't help. As per the crashlogs -> I would most certainly and happily get rid of a third party one, but it delivers more reports that Apple's own one. Perhaps I am doing something wrong but in the Organizer there's just less of them. Looking at Organizer though, the same crash report is also there and when I open the .xccrashpoint and dig in the folder structure and open any of the .crash items in the Logs directory, the same thread crashes occur: Thread 10 name: Thread 10 Crashed: 0 libdispatch.dylib 0x00000001a181de08 _dispatch_source_set_runloop_timer_4CF + 36 (sou

My reasoning is difficult to phrase in a way that will not come across as combative or insulting, but suffice to say I explicitly object to the existence of most--if not all--of the features that Apple has shipped in more recent releases and prefer to keep them all out of my house so to speak. I only update the OS when a machine dies and I have to buy a new one. If there's a solid guarantee that all of this is better in 15 then I'll absolutely bite that bullet anyway, but right now I'm essentially just doing a feasibility study and cannot destabilize everything else in my world just to find out whether or not maturity has crept in. My goal is simply an app with an overly-privileged helper that will never appear in any app store or be run on any machine that doesn't belong to a person who immediately disables SIP as a matter of principle. I've already removed all the PackageBuilder stuff as it was very much in the way of testing--that was the only sample project I could find that was close to what I wanted but

However, cross-referencing with the SysDiagnose logs, there is no corresponding process or activity for the application at the reported crash time. The newly uploaded logs in the feedback contain the relevant information regarding the issue. Unfortunately, the device was rebooted (at ~11:50am) before the sysdiagnose was triggered, which, unfortunately, renders the log largely useless for diagnostic purposes as log purging has destroyed too much context. In terms of what you said here: The app was not active, nor was it woken up by any event. I'm not sure what you mean here. There were three crash logs attached to the bugs. In all three cases, callservicesd initiated the launch: (1) PID 286: 2025-08-29 11:47:42.381409+0530 runningboardd: Acquiring assertion targeting app< ___ > from originator [osservice:35] with description attributes:[ 2025-08-29 11:47:42.381844+0530 runningboardd: Assertion 34-35-111 (target:app< ___ >) will be created as active 2025-08-29 11:47:42.418884+0530