LLDB crash

Reviewing the documentation and WWDC session I don't see anything about the Translation framework requiring the Translate app being installed. Unless I missed something, this could be bug. However, the settings area for the Translate app appears to be he place where you manage and download languages to available to the Translation framework. Are you making appropriate checks to make sure the languages you are trying to use are installed and available for translation? Please see the directions starting at ~ 12:00 in the following presentation for how to check if a language is available: Meet the Translation API If those checks fail, you can present directions for the user explaining how to fix the problem instead of crashing. If that does not help, our engineering teams need to investigate this issue, as resolution may involve changes to Apple's software. Please file a bug report, include a small Xcode project and some directions that can be used to reproduce the problem, and post the Feedback number

Please add some additional information to your bug report explaining what you were trying to do and the situation where this crash occurs. Add a small Xcode project that demonstrates the problem. Include some directions engineering can use together with your Xcode project to reproduce the problem.

Thanks so much for the response! clang and rustc (by design on Rust' part, to be clear!) are sufficiently similar that it was pretty easy to translate between C++ and Rust! Your tips/suggestions almost worked for me, except that the binary would be sigkilled'd immediately after launch. I did some rubber-duck debugging using Claude, and it—rather impressively!—pointed out in https://claude.ai/share/5a4ca3ca-9e98-4e2a-b9ae-71b49c6983cf that the entitlement I needed to use was com.apple.security.get-task-allow, not com.apple.security-get-task-allow. Instruments' diagnostic contained a typo! Once I fixed this typo, I was able to use the Processor Trace instrument via xctrace. Of course, since this is beta software, which I hit a few bugs, which I'll cover at the end of this post. Apple silicon code must be signed, so the linker automatically applies an ad-hoc signature. You can see this if you dump the hello tool before re-signing it: [dump redacted] If you’re going to re-sign the binary anyway, you can disable l

I'm having trouble reproducing the crash. What does your storyboard look like? You are using a UICollectionView with a custom layout (UICollectionViewCompositionalLayout by the looks of it). You have a subclass of UICollectionReusableView set as a header for the custom layout. According to the error message: must register a nib or a class for the identifier or connect a prototype cell in a storyboard I think this might be the other issue you are having. You can either manually register your custom class, like this: collectionView.register( EmotionFiltersHeaderView.self, forSupplementaryViewOfKind: ElementKind.sectionHeader.rawValue, withReuseIdentifier: emotionFiltersHeaderReusableView ) Or connect the reusable view in the storyboard (whatever that means). I would try manually registering first and see if that works. I'm not a fan of using storyboards, especially when working with collection views. With the introduction of compositional layouts, diffable data sources, and modern cell registrations —

Thanks @BabyJ. I have updated my code to address the discrepancy which you've noted. My code now looks like this: ` let section = NSCollectionLayoutSection(group: group) let headerSize = NSCollectionLayoutSize(widthDimension: .fractionalWidth(1.0), heightDimension: .estimated(37.0)) let header = NSCollectionLayoutBoundarySupplementaryItem( layoutSize: headerSize, elementKind: ElementKind.sectionHeader.rawValue, alignment: .topLeading) section.boundarySupplementaryItems = [header] emotionFiltersDataSource.supplementaryViewProvider = { collectionView, kind, indexPath in guard let headerView = collectionView.dequeueReusableSupplementaryView( ofKind: ElementKind.sectionHeader.rawValue, withReuseIdentifier: emotionFiltersHeaderReusableView, for: indexPath ) as? EmotionFiltersHeaderView else { fatalError(Could not dequeue header view as EmotionFiltersHeaderView) } let sectionTitle = Section.allCases[indexPath.section].rawValue headerView.sectionTitleLabel.text = sectionTitle return headerView } But I am still seein

Assuming the supplementary view has been registered properly, then the only other thing I see is that the element kind strings are mismatched. In your layout, you are specifying the elementKind as UICollectionView.elementKindSectionHeader (which is the string UICollectionElementKindSectionHeader). But when you dequeue the view, you are requesting it be of kind ElementKind.sectionHeader.rawValue (section-header-element-kind). I think this might be the cause of the crash.

@DTS Engineer Yes, we would greatly appreciate if Apple could look into this issue. This crash has already generated tens of thousands of crash reports in our app's backend, and we've also observed several similar crash logs in other health-related apps on Apple Watch. Thank you very much for your attention to this matter. ------------------------------------- Translated Report (Full Report Below) ------------------------------------- Incident Identifier: 74A69084-446E-461C-9401-FC97A426180B CrashReporter Key: 7d3c0ace745a10af53054a01d91601a47d39d41e Hardware Model: Watch7,5 Identifier: com.abc.watchkitapp Version: 2.1.0 (967) Code Type: ARM-64 (Native) Role: Non UI Parent Process: launchd [1] Coalition: com.abc.watchkitapp [633] Date/Time: 2025-07-02 20:38:25.6084 +0800 Launch Time: 2025-07-02 19:01:28.0292 +0800 OS Version: Watch OS 26.0 (23R5296f) Release Type: User Baseband Version: Report Version: 104 Exception Type: EXC_CRASH (SIGKILL) Exception Codes: 0x0000000000000000, 0x00

[quote='847039022, laesde, /thread/704718?answerId=847039022#847039022, /profile/laesde'] I can’t lock up the ips log files in Xcode Organizer. [/quote] Understood. Honestly, I don’t think getting more crash reports is going to help you here, and you’d be better off investing that time in trying to reproduce the issue. Clearly it’s a common problem, and Apple TV has a pretty limited configuration space, so this is more feasible than it would be, say, if this were happening on a Mac. First, survey your crash reports to see if they tell you anything about the device spread. The crash report you posted is from AppleTV6,2, that is, Apple TV 4K (1st generation). Are they all from that? Or are you seeing crashes from more modern Apple TVs. Similarly, do this analysis for the tvOS version spread. Also look at the app lifespan. In your crash the app had been running for 20-ish minutes. Is that typical? A memory problem like this is more likely to show up the longer the app

I’m glad to hear you’re making progress. [quote='847078022, FT-cfoy, /thread/791083?answerId=847078022#847078022, /profile/FT-cfoy'] The completion handler is spinning up a new thread [/quote] I noticed that the crashing code is being called out of Network framework. One thing to watch out for there is the type of queue that you pass into Network framework when you create your NWConnection [1]. Network framework will accept either a serial queue or a concurrent queue. Internally it does its own serialisation, so it doesn’t care. However, for your own sanity it’s important to use a serial queue. If you use a concurrent queue, it becomes very hard to reason about your code. Similarly, if you have multiple connections running simultaneously, it often makes sense to use the same serial queue for all of them. Oh, and be wary of concurrent queues in general. See Avoid Dispatch Global Concurrent Queues. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @

2025-06-09_18-48-03.1721_-0600-43bc27c538c2f93348a83e5380b5f016cc859f71.crash Thanks Quinn! I'm attaching one of the crash logs here. However your pointer got me to the issue - it's a race condition when the device is getting lots of messages over UDP from lots of other disparate devices and those messages are getting split over multiple packets. The completion handler is spinning up a new thread, but working off of the same instance of an underlying class which is where I think the issue is. I was able to replicate it by flooding the device with a bunch of partial messages randomly and could easily reproduce.