LLDB crash

Our engineering teams need to investigate this issue, as this might indicate an issue with iOS/macOS. 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.

Thank you for your reply. Certainly we have tried some memory debugging tools, but we didn't find any issues. I also find it extremely hard to believe that there was a problem with the system. I have been trying to figure out what our own issue might be. Simulated malloc guard detection is somewhat like our final attempt. Keep in mind that, when you operate at the scale of iOS, a ‘one in a million’ bug happens thousands of times a day O-: We cannot reproduce this issue locally. However, with our daily user traffic reaching billions, approximately 100 reports are generated every day. （This issue has some notable characteristics. Certain models account for a large proportion, especially iPhone 14,5.） I believe that the Apple receive an enormous number of abnormal reports every day. But how to determine whether these abnormalities are not caused by system issues or other common problems related to memory corruption? This is also why I think the feedback is necessary. If you saw some strange crashes, per

Thanks for the crash report link. I downloaded that successfully. As to why it was corrupted, I ran some tests here and confirmed that this a known bug in the DevForums platform (r. 136655649). Unfortunately, this is still a human readable crash report (.crash) and I’d ideally like to get a JSON one (.ips). If you find one of those, please share it here. However, I can still learn something from the report. First up, you’re calling JavaScriptCore from two threads, thread 2 and thread 16. Are you using different contexts for those? With different virtual machines? I’m not a JavaScriptCore expert but I believe that nothing good will come from you using the same context simultaneously on different threads. See this comment in the docs. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

This is most likely a memory corruption issue. If you forced me to guess, I’d say it most likely caused by a concurrency problem. In the code snippet you posted, is there any chance that currentDataStream can be accessed by multiple threads concurrently? Also: In situations like this I generally recommend that you apply the standard memory debugging tools, because they can make it easier to reproduce problems like this. Also, please post a full crash report, per the advice in Posting a Crash Report. That might reveal something else interesting. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Yes, even some times whenever you are on OTT overlay players and trying to use safari. the iOS and iPadOS crashing

However, even though it seems to be fixed in newer builds, from what I understand, for future-proofing it is generally not recommended to use dlclose() Correct. As Quinn noted, the ObjC and Swift runtimes don't actually support unloading, so unless you wrote the library and/or understand its full implementation, the behavior is basically undefined. Lots of libraries will unload without crashing, but in most cases that is an implementation accident, not any specific design choice. on libraries like libswiftDemangle.dylib even though I had manually dlopen()'ed previously, How it was opened doesn't matter. At a high level, the problem is that loading these libraries modifies your app’s internal state but unloading doesn't undo those changes. That leads to here: and keep such libraries loaded until the application exits? Depends on what you're actually doing. I don't know what you're actually trying to do, but the main reason apps want to load/unload libraries dynamically is that whatever they're doing i

So... Things I've tried so far: -Reboot : .. mail and safari crash as before... Re-install MacOS26: ,mail and safari crash as before... Looking at the stack dump, for both mail and safari, the crash is the same and seems to be related to webkit loading user fonts... 2 WebKit 0x1b216a050 WebKit::addUserInstalledFontURLs(NSString*,... I wonder if it's some really old font I've had for 10 years that was corrupt or something...

When adding the launch argument it straight away crashes on the fetch in the getHowManyProjectsToUpdate() method with Thread 9: EXC_BREAKPOINT (code=1, subcode=0x199aa51c4) The below is printed to the console CoreData: annotation: Core Data multi-threading assertions enabled.

As @deeje pointed out, using viewContext in a background queue, as shown in your following code snippet, does not follow the Core Data multi-threading programming pattern that requires the access to a Core Data context (NSManagedObjectContext) and its objects be from the context’s queue. DispatchQueue.global(qos: .background).async { while (getHowManyProjectsToUpdate() > 0) { leftToUpdate = getHowManyProjectsToUpdate() updateLocal() } ... } func updateLocal() { ... viewContext.refreshAllObjects() } Violating the programming pattern can trigger random crashes in Core Data, which probably explains the issue you described. With Xcode, you can use -com.apple.CoreData.ConcurrencyDebug 1 as a launch argument to check if your code has the concurrency issue. Note that the argument has the “-“ prefix. To do that: Open your project with Xcode. Click the target in the middle of Xcode’s title bar to show the drop list, and then click “Edit Schema...” to show the schema editing dialog. Add the argument to the

Not sure why that was in there twice, shouldn't be. I did originally save outside of the project loop but put it inside due to the crashing, as it would allow it to continue from where it left off.