LLDB crash

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

[quote='875671022, DTS Engineer, /thread/815033?answerId=875671022#875671022'] Given that you can reproduce this so easily, I recommend that you file a bug about it now. When doing that: Make sure to enable additional VPN logging, per the VPN (Network Extension) instructions on our Bug Reporting > Profiles and Logs page. After reproducing the problem, grab a sysdiagnose and attach it to your bug report. Once you’re done, post your bug number here. My plan is then to grab the crash report from your sysdiagnose log and dig a bit deeper. [/quote] Sounds good, thank you! Filed report: FB21933607 In addition to the sysdiagnose with the VPN logging profile enabled, I also attached a Minimum Failing Example similar to the code sample in the first message.

launch failed, RBSProcessExitContext voluntary I assume that you've discovered this message in the system log. Before going further, double check that it pertains to your app's process so that you don't go chasing down something that doesn't pertain to your app. Now, assuming that you've confirmed that, voluntary is the key word in that message — the most straight-forward explanation for when this happens is that a code path run by your app chose to call exit, ending your app’s process gracefully. This isn’t a crash, so there is no crash report that would backtrace right to the code path that made this call. As a starting point to locating any code paths in your app that call exit() directly, search your app’s entire source code for any calls to the system exit function, including any third-party libraries you use, and see what turns up. I sometimes like to use grep to find issues like these, should they turn up in unexpected corners, or potentially inside pre-compiled libraries that you can

OK, cool. Well, not cool, but you know what I mean (-: Given that you can reproduce this so easily, I recommend that you file a bug about it now. When doing that: Make sure to enable additional VPN logging, per the VPN (Network Extension) instructions on our Bug Reporting > Profiles and Logs page. After reproducing the problem, grab a sysdiagnose and attach it to your bug report. Once you’re done, post your bug number here. My plan is then to grab the crash report from your sysdiagnose log and dig a bit deeper. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

You mean that the compiler crashes? If so, that’s probably something best addressed over in Swift Forums > Using Swift. And speaking generally, to improve your chances of getting traction: Be clear about what version of the compiler you’re testing with. Isolate the code into a small test project that reproduces the issue. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com