LLDB crash

Thanks for the crash report. The standard DTS mantra is “Always ask for a crash report first.” I failed to do that in this case, to my own detriment )-: The crash report snippet in your original post, and the discussion of Rust and so on, confused me into thinking that this problem is more complex than it is. However, your crash report makes it clear as to exactly what’s going on: Thread 3 name: Thread 3 Crashed: 0 ??? 0x0000000000000000 0x0 + 0 1 sdk 0x0000000105931ec0 0x105820000 + 1121984 This isn’t a weird code signing issue. Rather, your code has simply jumped to nil. [quote='853477022, ospfranco, /thread/795348?answerId=853477022#853477022, /profile/ospfranco'] I guess cocoapods masqueraded the issue. [/quote] Possibly. I often see cross-platform code deploy the -undefined linker option, which has a tendency to turn build-time errors into run-time errors. Needless to say, I’m not a fan [1]. If you’re curious about how Mach-O symbols work, I talk about that ex

For those reading along at home, zhenYang sent me full copies of their crash reports via a different channel. Which is why I haven’t asked for them here (-: [quote='796647021, zhenYang, /thread/796647, /profile/zhenYang'] mainly occurring on iOS 16 systems [/quote] Mainly? Or exclusively? What’s the most modern OS release where you’ve seen this crash? Also, are you able to get a JSON format crash report (.ips) for this issue? If so, please post it here. That opens up more avenues for me to investigate this internally. See Posting a Crash Report for advice on how to post crash reports. ps The Radar bug indicated by that symbol name (r. 53306264) was resolved in iOS 13, so it’s unlikely to be a concern here. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

After Xcode26 beta5 update now facing same crash on iOS 26 devices.

After Xcode26 beta5 update now facing same crash on iOS 26 devices.

@DTS Engineer Here my crash report with sample project: FB19551898

@DTS Engineer I just tried the SPM version of the package and found out that on release config, it crashes with a undefined symbol. I guess cocoapods masqueraded the issue. When ran with the debug scheme then it runs fine. The Package.swift is defined as follows // swift-tools-version: 5.8 import PackageDescription let package = Package( name: OpacityCore, platforms: [ .iOS(.v13) ], products: [ .library( name: OpacityCore, targets: [OpacityCoreObjc, OpacityCoreSwift]) ], dependencies: [], targets: [ .binaryTarget( name: sdk, path: sdk.xcframework ), .target( name: OpacityCoreObjc, dependencies: [sdk], path: src/objc, publicHeadersPath: ., cSettings: [ .headerSearchPath(../../include) ], linkerSettings: [ .linkedFramework(CoreTelephony), .linkedFramework(CoreLocation), .linkedFramework(WebKit), ] ), .target( name: OpacityCoreSwift, dependencies: [OpacityCoreObjc], path: src/swift ), ] )

Here's the exception info: EXC_CRASH:Object-C Exception:-[CALayer setPosition:] position contains NaN:[nan 41] The crash seems triggering when user tap text in input box and call editmenu, and the position of the menuview is wrong(contains nan) for some reason,but I can't reproduce this in debug mode.

Just Package.swift with SPM 900 targets Wow, that's quite the package! Please file this as a bug report with your crash report and reproducer project attached, and post the FB number here for reference. — Ed Ford,  DTS Engineer

It is a question of timing. When onAppear returns, and DataView is called, the array is not yet populated, even though its count is already OK. You have to wait for a short time in onAppear (0.01 s should be OK). Here is the solution. I had to rename Data to avoid the error above (Data is a Foundation type). I renamed to Data2 struct Data2: Decodable, Hashable { let index: Int let str: String } struct DataView: View { @State var data: Data2 var body: some View { Text(DataView (data.str)) } } struct ContentView: View { @State var showView = false // To wait for array to be populated before we display the view @State var data: [Data2] @State var index: Int = 0 var body: some View { VStack { if showView { DataView(data: data[index]) // Text(Hello (data.count)) // To test if needed ; without async, data.count is 2. Seems OK, but… // Text(Hello (data.count) index (index) (data[0].str)) // but without async, it will crash, as data is not populated yet, even if count is already 2 } } .onAppear { let filePat

I don't understand. Aren't all these tools you mention (Zombies instrument, ASan, Main Thread Checker etc.) meant to be run in Xcode or Instruments? Or are you saying I should enable some compiler flag in my production build? The thing that makes over-release issues (and most other memory crashes ) hard to debug is that the crash log you’re looking at is NOT why your app crashed. I'm not sure I understand. Is it correct that the line in the crash log myEntity.image = newImage is trying to retain an image that was over-released or is being deallocated, but the thing that over-released it is possibly somewhere else? What thread is myEntity.image accessed on? I mentioned in my original post that it's called on the main thread, and I just checked again and can confirm it. Just to be sure, I'll put a if !Thread.isMainThread { preconditionFailure() } in the next app update, so there won't be a shadow of a doubt anymore. Though it will take a couple weeks before the update is publ

Could you provide complete code as well as the json file ? Is Data a structure you have defined ? If it is an empty set, it should crash at: DataView(data: data[index]) Do you get Fail messages ? Problem is not in onAppear. I tested by replacing getData by a dummy call .onAppear { // let filePath = Bundle.main.path(forResource: data, ofType: json) // let url = URL(fileURLWithPath: filePath!) // // data = getData(url: url) data = [Data()] } And data DataView is not empty, as I could check with the following struct DataView: View { @State var data: Data var body: some View { Text(DataView (data)) } } So, it looks like you return from getData by line 29 and not 22. So, could you change line 29, to return a custom single data to check ?

Thanks. So it sounds like the NSImage is getting over-released or being incorrectly deallocated, although it's unclear to me what exactly is trying to form a weak reference, since my code (as shown above) has a strong reference. Unfortunately, the higher up function calls are made by AppKit, which is not open source, so I cannot look it up. Seeing that code wouldn't actually help. The thing that makes over-release issues (and most other memory crashes ) hard to debug is that the crash log you’re looking at is NOT why your app crashed. At some earlier point in your app, something happened in your app that caused an extra release that would not normally occur. In other words, what the crash log shows is a victim of an underlying issue, not its direct cause. As far as I understand, the link you posted helps investigating memory issues in Xcode, but since the crash reports are downloaded by Xcode from other users and I cannot reproduce it myself... I should have posted

The best approach would be to file a bug report and attach the complete crash log to it. First, please fully symbolicate the crash log using the information at Adding identifiable symbol names to a crash report Then, please 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. Bug Reporting: How and Why? has tips on creating a successful bug report.

Our engineering teams need 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. Bug Reporting: How and Why? has tips on creating a successful bug report.