LLDB crash

To eliminate potential race conditions, we have also moved our interrupt handling to the Default Dispatch Queue using kIOServiceDefaultQueueName. I'm not sure you want to do this, as I think it might end up causing BundledParallelTaskCompletion() to deadlock itself. As soon as the completion is triggered from the asynchronous interrupt path—even though it is serialized on the same Default Queue—invoking ParallelTaskCompletion (or BundledParallelTaskCompletion) causes the DEXT to crash immediately (Corpse / Address size fault). Can you post the crash log for this? We extracted our core logic into a helper method, DispatchTaskInternal, passing 0xFFFF as a placeholder for the Slot Index. Is your DispatchTaskInternal method just a simple helper method/function or is it actually running on a different queue? If it's on a different queue, then I would strongly suggest that you eliminate that entirely and just do everything on the same thread. The issue here is that, in practice, most of what your

Thanks Quinn, much appreciated. I'll add that I've also tried Soft Mode extensively and I've never seen it do anything. No log messages, no crashes in the debugger, no crash reports in the on-device logs for MTE. I'm open to suggestions! Occasionally I can get a crash in _zxm_xzone_malloc_free_outlined in an unrelated stack but this appears to be regular old corruption rather than MTE kicking in.

So, when running outside of the debug, MIE can run in one of two modes: In soft mode, it generates simulated crash reports for violations. In hard mode, it crashes the process. My understanding is that hard mode is not yet support for third-party apps. The weird part is that I can’t find that documented anywhere. I’m gonna research why that’s not the case and get back to you. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Hi all, we do have the same problem. Me and several other colleagues. We just found out the same that iOS Simulator version 18.2 is the latest working for us. We have also tried to clean everything and start the installation from scratch. It did not help. I throw my stack trace here as well in the hope it might be seen and it might help some developer at Apple. Unable to boot the Simulator. Domain: NSPOSIXErrorDomain Code: 4 Failure Reason: Interrupted system call User Info: { DVTErrorCreationDateKey = 2026-01-14 08:42:36 +0000; IDERunOperationFailingWorker = _IDEInstalliPhoneSimulatorWorker; Session = com.apple.CoreSimulator.SimDevice.79733B3C-A5BA-41E8-A88A-6DA408E517D6; } -- Failed to start launchd_sim: could not bind to session, launchd_sim may have crashed or quit responding Domain: com.apple.SimLaunchHostService.RequestError Code: 4 -- Event Metadata: com.apple.dt.IDERunOperationWorkerFinished : { device_identifier = XXX; device_model = iPhone17,5; device_osBuild = 26.0 (23A339); device_osBuild

For the record, I've made no further progress triggering an MTE crash using only the entitlements. I tried a more extreme pointer manipulation and it still proceeds just fine: // Now guarantee a tag mismatch by modifying p2's tag unsigned old_tag = PTR_TAG(p2); unsigned new_tag = (old_tag + 1) % 16; uintptr_t addr_only = (uintptr_t)p2 & 0x00FFFFFFFFFFFFFF; void *p2_bad_tag = (void *)(addr_only | ((uintptr_t)new_tag << 56)); os_log(OS_LOG_DEFAULT, Original tag: %u, Modified tag: %un, PTR_TAG(p2), PTR_TAG(p2_bad_tag)); os_log(OS_LOG_DEFAULT, Attempting read with guaranteed bad tag...n); volatile char c2 = *(volatile char *)p2_bad_tag; // Should this crash? os_log(OS_LOG_DEFAULT, Read succeeded! Value: %dn, c2); yields Original tag: 14, Modified tag: 15 Attempting read with guaranteed bad tag... Read succeeded! Value: 31

Hi Kevin, Thank you for your valuable insights. Following your advice, we have refactored our driver to use a wrapper pattern where UserProcessBundledParallelTasks serves as a high-performance entry point that forwards commands to our core dispatch logic. To eliminate potential race conditions, we have also moved our interrupt handling to the Default Dispatch Queue using kIOServiceDefaultQueueName. This ensures that command submission and completion are strictly serialized. Here are the key implementation details showing how we unified the dispatch logic: 1. Legacy Entry Point (Single Task): We extracted our core logic into a helper method, DispatchTaskInternal, passing 0xFFFF as a placeholder for the Slot Index. kern_return_t MyDriver::UserProcessParallelTask_Impl( SCSIUserParallelTask parallelRequest, uint32_t *response, OSAction *completion) { // Forward to unified internal dispatcher with no slot index (Legacy Mode) return DispatchTaskInternal(parallelRequest, response, completion, 0xFFFF); } 2. Bundled S

@MadBha @Divyajain Investigating this, we found out that what you are describing with the second accessory setup causing power state change, was a known issue with iOS 18, but has since been fixed in iOS 26. If you are seeing this issue with iOS 26, then we will need some diagnostic logs to understand what might be happening. To help our Bluetooth team to investigate this issue, we'd greatly appreciate it if you could open a bug report, include crash logs and sample code or models that reproduce the issue, and post the FB number here once you do. FIrst, to create a diagnostic log, please go to https://developer.apple.com/bug-reporting/profiles-and-logs/ and follow the instructions for Accessory Setup Kit for iOS< and Bluetooth for iOS to install those logging profiles on your device. Then reproduce the issue, and follow the instructions at the above link to create a sysdiagnose. And then attach that to the bug report as well. Bug Reporting: How and Why? has tips on creating a successful bug report

Thanks for the post. It seems like you're experiencing issues with Xcode 26.2 on macOS Sequoia. So the preview stops rendering anything in a simple Hello World app? Would you like to post the app here for developers to test and see how it behaves? If so, please share a link to your test project. That'll help us better understand what's going on. If you're not familiar with preparing a test project, take a look at Creating a test project. Verify that both your macOS and Xcode versions are fully updated. Since you're on Sequoia 15.7.3 and Xcode 26.2, check for any available updates for macOS that might address. I would recommend to move to macOS Tahoe. Sometimes, clearing derived data can resolve issues related to indexing and builds. You can do this by navigating to and deleting the contents. If the canvas is causing Xcode to hang, try disabling it temporarily. Open your project settings, navigate to the section, and uncheck “Live Views”. As a more drastic measure, consider completely uninstalling Xcode and re

I have to say, I and everyone else in my team are very happy to see you analyse the dump of logs there. We had tried to read them many a times, but we did not manage to extract the insight you have. Thank you so much for the help. We will get rid of Go and it's weird stacks, but as per the docs (https://pkg.go.dev/os/signal#hdr-Non_Go_programs_that_call_Go_code) we might be installing some signal handlers, inadvertently. However, the original signal handlers should still be invoked, as pre the docs. For reference, we build the go library with buildmode c-archive. Even still, as per the docs, any time a signal is delivered, it should be handled the original signal handler, unless it was invoked on a Go routine. I would not be surprised if using Go in an iOS app was unsafe at any speed. So, something in your process is doing a synchronous blocking read on a pipe and that’s blocked indefinitely. And we can’t figure out what it is because the spindump isn’t showing the user-space component of the backtrace. Given

I’m gonna shelve the SIGTERM issue for the moment… Bah, no, I can’t let that go. My original question still stands here: Why are you getting involved in SIGTERM at all? This matters because there’s evidence to suggest that your packet tunnel provider is not stopping when asked, and SIGTERM can be a factor in that. Also, I don’t see any crash reports in the sysdiagnose log, and it’s not uncommon for signals handlers to interfere with crash report generation. So I’d like to get a handle on why SIGTERM comes into play here, and if any other signal handlers are installed. That is … is the real deal. Cool. For reference, I’m working from sysdiagnose_2024.10.17_10-27-27+0200_iPhone-OS_iPhone_22A3370_44011817.tar.gz. I opened system_logs.logarchive and started poking around. In the last 30 minutes of the system log I see three failures to start the VPN: type: default time: 2024-10-17 10:18:56.832535 +0200 process: APP_NAME subsystem: com.apple.networkextension message: Last disconnect error for CON

[quote='872001022, shenbj, /thread/812455?answerId=872001022#872001022, /profile/shenbj'] Here is the Crash Report [/quote] Unfortunately that crash report is not doing what I need it to do. It’s possible that was munged by the forums platform [1]. It’s also possible that your redaction efforts caused something to break. [quote='871930022, , /thread/812455?answerId=871930022#871930022'] Also, please post the Feedback Report number. [/quote] Yeah, I think that’s the best way to make progress here. shenbj, Please file a bug about this, attaching some example crash reports, and then reply here with the bug number. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] This is, alas, a known bug (r. 136655649).