LLDB crash

You are not alone - I have the same thing happening, plus the DuckDuck Go browser also crashing on launch. At least trusty Firefox works! I have filed reports on each of the crash on launch issues.

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