LLDB crash

@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).

Here is the Crash Report 20260113.crash

FB20843042 is the feedback we filed which includes a sample project. What is the intent of foo(key: MyCustomTraitKey.self)? It was added in an effort to identify the source of the crash by minimizing types and functions used from system SDKs. The issue occurs with any function with the same signature. The original ossie wsa found when calling https://developer.apple.com/documentation/swiftui/environmentvalues/subscript(_:)-9zku

That is a sysdiagnose from 2 almost years ago where we caught the bug on a colleagues device. It is the real deal. As far as signal handlers go, we are doing our best to avoid them, but it might be the case that the signal handlers are being executed on threads that are attempting to run Go code. It is a problem because the Go runtime implements cooperative thread scheduling where each thread gets a tiny stack. Such a thread would most definitely crash if a signal handler was invoked on top of it - some goroutine stacks are bound to be smashed. This is however a detour, I believe. I do not believe that the packet tunnel profile corruption (?) is an issue that is bespoke to Go or to our implementation of our tunnel. Further, it is my understanding that if our tunnel process is receiving signals, it probably is already too late. Why Go? Because the first WireGuard implementation that wasn't a Linux kernel module was implemented in Go. Just for the record, we are in the process of moving away from a Wir

When using UITraitBridgedEnvironmentKey to pass a trait value to the swift environment, it causes a crash when trying to access the value from the environment. What is the intent of foo(key: MyCustomTraitKey.self)? Have you tried using registerForTraitChanges(_:handler:) to observe the trait changes ?

Due to the very low latency of our hardware for specific commands (e.g., TEST UNIT READY). Logs reveal a severe timing conflict: The interrupt handler (Completion path) is triggered and successfully invokes BundledParallelTaskCompletion, which returns normally. Crucially, at this exact microsecond, the original UserProcessBundledParallelTasks call (Submission path) has not yet finished its loop or returned to the system. Immediately after both paths eventually return, the DEXT process crashes (Corpse), subsequently triggering a Kernel Panic. Something doesn't sounds right here. There are actually a few different things that concern me: (1) There's a reasonably long cycle to get to your interrupt handler from the kernel. I'm skeptical that there's any way for an interrupted to fire before UserProcessBundledParallelTasks finishes running unless UserProcessBundledParallelTasks is doing something that substantially delays its own process. (2) From the kernel side, how bundled commands actually work is th