LLDB crash

I've entered FB21953216 with 2 crash logs attached. Both show multiple threads calling SB (job thread names begin with ProofProcessor). One has 3 jobs and the other has 4. Perfect. I'm glad I asked, as I think I know what the problem is. Going back to my previous message, I said: Also, as a specific detail, how are you actually creating these threads and, in particular, these are standard threads (NSThread/pthread) NOT something fancy like GCD or Swift Async. So, looking at your code, my immediate concern is that you're using NSOperation to run your SBApplication, which means you're using GCD. It looks like the operation itself is a monolithic task attached to one thread (otherwise, this would be REALLY bad) that's destroyed at completion, so I assume that you're creating and destroying the SBApplication for every operation. Theoretically that's relatively safe; however, at a minimum it means you're likely leaking mach ports, which is a risk I'd work VERY hard to avoid. In terms of using your existin

Dear xiewk, Thank you for that crash snippet, however can you please attach a proper .ips file by following the instructions in Posting a Crash Report and Acquiring crash reports and diagnostic logs so we can analyze it accordingly? Thanks, Richard Yeh  Developer Technical Support

[quote='876059022, jzilske, /thread/815493?answerId=876059022#876059022, /profile/jzilske'] the exception reason tripped me up at first: [/quote] Yeah, I’ve been mislead by that in the past. Fortunately, this time I remembered the mantra that we here in DTS chant steadily throughout the day: Always start with a crash report. Always start with a crash report. Almost start with a crash report. … (-: Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Thanks, Kevin. I've entered FB21953216 with 2 crash logs attached. Both show multiple threads calling SB (job thread names begin with ProofProcessor). One has 3 jobs and the other has 4. Our app can run up to 40 jobs concurrently, but rarely get more than half a dozen, usually just a few. Each job can run a unique instance of InDesignServer. Our app runs forever. Before moving to ScriptingBridge, we did run into the problem of only being able to run one script at a time from the main thread, so we added an external app and each job launched one of those to run the scripts. I don't recall the exact security changes nor in which OS we found that a change to ScriptingBridge was needed. A different engineer handled that change.

Our app can run multiple jobs concurrently, each in its own NSOperation. Each op creates its own SBApplication instance that controls unique instances of InDesignServer. What I'm seeing recently is lots of crashes happening while multiple ops are calling into ScriptingBridge. Shown at the bottom is one of the stack crawls from one of the threads. Can you attach a full crash log? If it's too long or you don't want to share it publicly, you can also file a bug, upload the logs there, then post the bug number back here. I want to see the full app context and crash state, just in case there is something else going on. Also, as a specific detail, how are you actually creating these threads and, in particular, these are standard threads (NSThread/pthread) NOT something fancy like GCD or Swift Async. In searching for answers, Google's AI overview mentions If you must use multiple threads, ensure that each thread creates its own SBApplication instance… Which is what we do. No thread can rea

Does this general a crash report? If so, please post an example here. See Posting a Crash Report for advice on how to do that. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

So, let me start by going back to what I said here: ...is an XPC connection failure with callservicesd, typically caused by callservicesd crashing. That's not common, so if your app is causing frequent resets, then that's an issue that might be worth looking into. By definition, that's not a normal failure. Your app is basically being notified of a failure because it's not clear what else we can/should do. That also means I don't necessarily have a great solution, certainly not one I can guarantee to be reliable. That leads to here: there is no initial providerDidBegin for first CXProvider as logger misses early logs Do you have any sense about how long your app is typically able to stay active, both in terms of being awake/active and in absolute terms (wake or suspended)? This primarily comes up with long-running kiosks apps, but one of the issues that can happen to long-running apps is that as they get better and better at working for very long periods of time (in kiosk apps, this is typically days

Crash still exists with 26.3. Created FB21940939

Hi Kevin, Thank you for your feedback and the feedback from the engineering team. We have integrated all suggestions from your forum posts (ID: 875288022, 875587022) and the Bug Report, and have conducted a full round of testing. Below is our current status. We now perform a memset on SCSIUserParallelResponse in the ISR and correctly populate the version, fControllerTaskIdentifier, and fBytesTransferred fields. The ISR now differentiates between Bundled/Legacy modes, calling BundledParallelTaskCompletion (without release()) and ParallelTaskCompletion (with release()) accordingly. The aforementioned fixes have resolved all 0x92000006 Panics and DEXT Corpse crashes. Unplugging the hardware or deactivating the DEXT while the driver is in a hung state no longer triggers a panic. We are in a logical deadlock. The kernel dispatches a probe command before UserCreateTargetForID returns, and both of our methods for handling this command result in a permanent hang of the registration process: Scenario A (Repor