“LLDB crash”

Hi Kevin, thanks for the response, really appreciate it. I am putting the log below, which is getting on the Mac console when the app is crashing. Yes, that's the standard log message that happens when your app crashes itself for failing to report a call to CallKit. To say more about what's actually going on, I'd need to see the actual crash log. See this forum post for more information about how to get the log and then post it to the forums. Is this enough or do you need anything specific? Let me know if anything is needed. Thanks for the effort. I'm happy to take a look at the log, but the basic answer here is that your app is doing something wrong- either by not reporting a call, or by blocking inside didReceiveIncomingPushWith for an extended period of time (it shouldn't really need to block at all). __ Kevin Elliott DTS Engineer, CoreOS/Hardware

Splitting for length, part 2... Moving on to specifics: I need to decide whether a file-system object (from the ES message) is a Document, in my own semantics. As a general comment, you should be aware that relying on data read from the file system opens you up to a variety of TOCTU attacks. That may not be avoidable, but the risk is quite real. A document is any normal file, or -- package directories. If the file-system object exists and is a directory, and it has a file-name extension, I use something like: How is your ES client being run? Assuming you're running as a daemon, then you should not be calling NSWorkspace, as AppKit is definitely NOT daemon safe. In this particular case, it's easy to replace as isFilePackageAtPath is actually just a trivial wrapper around NSURL.getResourceValue:forKey: which is checking NSURLIsPackageKey. However, I'd strongly recommend taking a look at any other usage of NSWorkspace. If it is non-existing (to be created etc.) Then I use this heuristic and API: Have you impleme

Splitting for length, part 1... I will also attach a sample crash report. So, let me start there. All three logs have threads blocked in dispatch_sync, with the worst case having 35 threads blocked in this code chunk waiting for another thread to clear the block: 6 libdispatch.dylib 0x7ff80f50468e _dispatch_sync_f_slow + 175 7 com.proofpoint.itm.prevention 0x10a102a81 8 com.proofpoint.itm.prevention 0x10a0ff5cb 9 com.proofpoint.itm.prevention 0x10a0ff482 10 com.proofpoint.itm.prevention 0x10a0c5716 11 libdispatch.dylib 0x7ff80f4f76b9 _dispatch_call_block_and_release + 12 The other two logs are that extreme, but both of them also show blocks in dispatch_sync and one of them also shows the same contentions (though not as extreme). I have some general comments below, but the critical next step here is to fully symbolicate these logs and figure out what your client is actually doing. You're clearly bottlenecking on something and figuring out what that is is obviously an important first step. I obviously

Lucky me - it crashed today! Crash log and sysdiagnose uploaded to bug report FB21953216.

It appears to be related explicitly to persistent store. Removing the assign call allows the object to be created, modified, saved as expected. Further, I tried to editing objects with the following code let managedObjectContext = managedObjectContext.child(with: .mainQueueConcurrencyType) let object = managedObjectContext.object(with: objectID) as! Object And this crashed with Thread 1: Object 0x82018e630c8dd320 persistent store is not reachable from this NSManagedObjectContext's coordinator Again, this isn't an issue for iOS, but it does appear to be an issue for both Mac and VisionOS. It's also not feasible to provide a minimal project that is minimal.

Thank you so much for the elaborate and helpful reply. I will try to address each point, to try and see how to close in on my problem. I will also attach a sample crash-report. My rule engine is very fast, based on NSPredicates over ObjC custom classes (No core-data etc.). Rule evaluation is completely internal to my daemon, no API calls and no external calls. There IS , however a stage prior to rule evaluation, where I Parse ES messages into my custom ObjC class, and in that stage there are few API calls one of which has given me grief in the past. I need to decide whether a file-system object (from the ES message) is a Document, in my own semantics. A document is any normal file, or -- package directories. If the file-system object exists and is a directory, and it has a file-name extension, I use something like: _isDocument = [[NSWorkspace sharedWorkspace] isFilePackageAtPath:_filePath ]; If it is non-existing (to be created etc.) Then I use this heuristics and API: { // non-existing directory obj

Hi Kevin thanks for the response, really appreciate it. am putting the log below, which isgetting on Mac console when app is crashing default 23:17:22.391093-0600 callservicesd Registering client process with bundle identifier for PushKit voip in environment development default 23:17:23.060244-0600 callservicesd XPC PushKit connection invalidated from client default 23:17:23.060353-0600 callservicesd XPC PushKit connection invalidated from client default 23:17:23.060420-0600 callservicesd XPC PushKit connection invalidated from client default 23:17:54.295556-0600 callservicesd Pending PushKit VoIP payload deliveries until a connection exists default 23:17:54.385566-0600 callservicesd Registering client process with bundle identifier for PushKit voip in environment development default 23:17:54.576781-0600 callservicesd Registering client process with bundle identifier for PushKit voip in environment development default 23:17:58.781527-0600 callservicesd Registering client process with bundle identifie

Until 26.4 is generally available, I have found an ugly, but usable, workaround: First perform method swizzling to replace addSubiew:, then in the replacement implementation do nothing when a view is being added to it self This will avoid the crash, but results in a graphic glitch where the selection overlay is opaque over some tabs. Very ugly. To solve this problem: Implement the tab-bar-controller delegate method to detect when customization has ended. When it has ended, set the tab-bar-controller's view-controllers to just the first view-controller, without animation. Then immediately restore the original set of view-controllers, again without animation. This will force the tab-bar to refresh and resolve the graphic glitch from (1) Finally, set the more-view-controller as the selected-view-controller again, since the re-setting of view-controllers in (2) will reset the selected tab. With the above, I do not experience crashes, and there is about 1/2 a second of visual glitching, but thing

The test using a fake job did not cause a crash, only a hang of the ProofProcessor - FAKE1 NSOperation. I'll grab a sysdiagnose the next time this happens, which could be tomorrow. There's currently one user's job that is repeatedly causing an exception to be thrown while sending AppleEvents via ScriptingBridge. It's probably related, but is not causing the same 2 jobs sending AEs and causing the crash situation.

First up, on the bug side, what would be most useful now would be to capture a sysdiagnose after the crash, then upload that log to the bug. A few notes on that: The log doesn't need to be collected all that soon after the bug. I try to collect within a few minutes of the crash, but there really isn't any difference triggering within the next 15+ minutes. Eventually, we start purging log data (losing data), but I've gotten useful data out of logs that were taken hours after the event. It IS important that you not reboot the machine first. Lots of data is purged during that process, to the point where I've basically found those logs useless. PLEASE include information about WHEN the problem occurred. Even better, upload the crash log from the same crash you want to use to look at in the sysdiagnose. The log volume is so high that trying to figure out what happened without a time reference can be extremely slow and time-consuming. Similarly, the crash log should be i