What's the "architecture" of that helper app? Is it a true "app" (meaning, in an app bundle, running an NSApplication loop, and simply marked "faceless")? Or is it something like an XPCService or a command-line tool? Also, how was it launched? The applescriptrunner helper app is just a command line app launched with NSTask, using a NSXPCConnection, et al. That app's main() creates an NSOperation subclass that handles all of the XPC communication and running of scripts (formerly via NSAppleScript, but now via ScriptingBridge). I assume this is communicating with the "server app", so there isn't a user-visible app either? If so, then my best guess would be that we're suspending the app or otherwise stopping/pausing its normal execution. It happens with both InDesign Desktop (UI) and InDesignServer (no UI). How long does it stay stuck like this? It doesn't actually "stick", it just returns nothing from InDesign when the script should return a result or throws an error. From the reply I got in my ticket for that situation (FB22065804), it's InDesign's bug that's causing this.

I've made a change to our app. We have a faceless helper app that we used to use for running all our scripts. It uses XPC for communication between it and the main app. It was developed many years ago when we needed to stop blocking the main thread when multiple jobs were running scripts. I updated it a few days ago to use ScriptingBridge (like we'd previously done to the main app). This has been used in production now for a couple days. We no longer experience crashes caused by the low level AE system (AECreateEmptyEvent, etc). That's the good news—the AE errors for one job no longer take out the app and any other jobs. I do still get problems that appear to be empty replies from telling the InDesignApplication (an SBApplication subclass) to doScript:ourScript. This mostly happens when running multiple jobs at once and when I switch our main app in and out of the foreground. I assume doing that jiggles a lot of Jell-o. I don't know what would cause that; the AE system, SB, or InDesign.

Hooboy, knowing if we've seen it on Intel machines will take some digging. The M1 Studios we have are 2022. Our ScriptingBridge code was added in June 2023. The first internal mention of errOSAInternalTableOverflow is December 2023. The M1 Studios weren't put into production until March 2024 (that's how slow our IT department moves). By this timeline, it appears we were seeing errOSAInternalTableOverflow on Intel. As for the actual crash described in this thread and bug, that I'm not sure about. I'm assuming that getting errOSAInternalTableOverflow and this crash are caused by the same underlying bug. No PowerPC Macs have been in use during my tenure at this job. Naturally, I figured it would be a very long time until a possible Apple fix would reach our production machines. Time to diagnose + time to fix & test + time to release + time for our IT department to OK the user of that version of macOS. I just might be retired by then. Moving the bulk of the "job" code to a separate helper app will be fairly substantial for our small team. I might've mentioned that during my stress testing to duplicate the problem, I tried using a class-level lock around the call into ScriptingBridge. That appeared to help, but made the app essentially single threaded, and that's not an option. I'll mess with adding a small delay, although that will be quite ugly in the dozen or so methods that we've rewritten to be full ScriptingBridge calls (multiple lines accessing objects and calling SB methods on the target app, rather than just telling the SB app to run an AppleScript). I'll also mention that today I tried having 2 jobs running, each hammering a different target SB app. At times one of the operation would freeze inside the AESendMessage: #0 0x0000000188941c34 in mach_msg2_trap () #1 0x0000000188954338 in mach_msg2_internal () #2 0x000000018894a764 in mach_msg_overwrite () #3 0x0000000188941fa8 in mach_msg () #4 0x0000000188a6ec0c in __CFRunLoopServiceMachPort () #5 0x0000000188a6d528 in __CFRunLoopRun () #6 0x0000000188a6c9e8 in CFRunLoopRunSpecific () #7 0x0000000190494198 in ___lldb_unnamed_symbol1373 () #8 0x000000019047098c in AESendMessage () #9 0x00000001d52402ac in -[SBAppContext sendEvent:error:] () #10 0x00000001d523988c in -[SBObject sendEvent:id:parameters:] () The other operation carried on running. Sometimes I could make it unfreeze by stopping in the debugger to see what it was doing, then continue. Then the other operation might freeze later. Etc. And sometimes, if I just let it sit long enough, the frozen operation would continue on its own, although I don't know if that ever happened while both operations were present and running.

Good idea. I often have most of that stuff turned on, but haven't lately. I ran with ASan on all this morning (running 2 jobs that constantly hammer InDesign Desktop with scripts) and only managed to get 2 occurrences of errOSAInternalTableOverflow, but no crashes or hangs.

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

I've submitted bug FB22065804 and attached files created shortly after the error concerned. Oh, I'll add the time the error occurred to the bug. I forgot about that.

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.

Another crash log added to the bug, in case it helps.

I have a small external app that puts up a modal dlog on receipt of the openDocuments event. I created a fake job in the big app that sends all the events, and had it send an kAEOpenDocuments to the small app, using kAEWaitReply so it will just sit there until the small app dismisses the modal dlog. I then ran a normal job that hammers InDesign with thousands of scripts. I got this in the Xcode log of the big app: AddInstanceForFactory: No factory registered for id <CFUUID 0x600003aad120> F8BB1C28-BAE8-11D6-9C31-00039315CD46 A few minutes later the big job got stuck and I noticed two of these in the Xcode log: Received XPC error Connection interrupted for message type 1 kCFNetworkAgentXPCMessageTypePACQuery The big job's thread at this point: ProofProcessor - FAKE1 Queue : Job Queue (QOS: USER_INITIATED) (concurrent) #0 0x00000001948e1c34 in mach_msg2_trap () #1 0x00000001948f43a0 in mach_msg2_internal () #2 0x00000001948ea764 in mach_msg_overwrite () #3 0x00000001948e1fa8 in mach_msg () #4 0x0000000194a0ec0c in __CFRunLoopServiceMachPort () #5 0x0000000194a0d528 in __CFRunLoopRun () #6 0x0000000194a0c9e8 in CFRunLoopRunSpecific () #7 0x000000019c434108 in ___lldb_unnamed_symbol1373 () #8 0x000000019c4108fc in AESendMessage () #9 0x00000001e11dd2ac in -[SBAppContext sendEvent:error:] () #10 0x00000001e11d69d8 in -[SBObject sendEvent:id:format:] () #11 0x00000001e11d43d8 in -[SBElementArray count] () #12 0x00000001949ba7e4 in -[NSArray getObjects:range:] () #13 0x00000001949feae0 in -[NSArray countByEnumeratingWithState:objects:count:] () #14 0x0000000102b27054 in -[InDesignHelper(ScriptingBrigePageItems) idsAndLabelsOfAllPageItemsRecursivelyForDocSB:includeMasterSpreads:] at /Users/xxx/Documents/gitdepot/RRDFramework/InDesignHelperScriptingBridge/InDesignHelperSBPageItems.m:105 #15 0x0000000102c90704 in __82-[InDesignHelper idsAndLabelsOfAllPagesItemsRecursivelyforDoc:includeMasterPages:]_block_invoke at /Users/xxx/Documents/gitdepot/RRDFramework/InDesignHelper.m:2887 #16 0x0000000102ce8820 in -[InDesignHelper _callSBMethod:scriptName:docID:] at /Users/xxx/Documents/gitdepot/RRDFramework/InDesignHelper.m:6160 #17 0x0000000102c901d4 in -[InDesignHelper idsAndLabelsOfAllPagesItemsRecursivelyforDoc:includeMasterPages:] at /Users/xxx/Documents/gitdepot/RRDFramework/InDesignHelper.m:2887 #18 0x00000001008c7dc4 in -[FakeProof allPageItemIDs] at /Users/xxx/Documents/gitdepot/MMAutomation/FakeProof.m:302 #19 0x00000001008c3bf4 in -[FakeProof _doProofProcessing] at /Users/xxx/Documents/gitdepot/MMAutomation/FakeProof.m:89 #20 0x000000010094da10 in -[ACDCProof processProof] at /Users/xxx/Documents/gitdepot/MMAutomation/ACDCProof.m:133 #21 0x0000000100ab3300 in -[ProofProcessor _processDriverFile:] at /Users/xxx/Documents/gitdepot/MMAutomation/ProofProcessor.m:989 #22 0x0000000100aa3fd4 in -[ProofProcessor main] at /Users/xxx/Documents/gitdepot/MMAutomation/ProofProcessor.m:187 #23 0x0000000195fc0f0c in __NSOPERATION_IS_INVOKING_MAIN__ () #24 0x0000000195fc027c in -[NSOperation start] () #25 0x0000000195fbfff4 in __NSOPERATIONQUEUE_IS_STARTING_AN_OPERATION__ () #26 0x0000000195fbfee4 in __NSOQSchedule_f () #27 0x0000000100f78514 in _dispatch_call_block_and_release () #28 0x0000000100f952dc in _dispatch_client_callout () #29 0x0000000100f7c274 in _dispatch_continuation_pop () #30 0x0000000100fb5290 in _dispatch_async_redirect_invoke () #31 0x0000000100f8e30c in _dispatch_root_queue_drain () #32 0x0000000100f8ee2c in _dispatch_worker_thread2 () #33 0x000000010101b768 in _pthread_wqthread () Is any of that helpful?

(2) Redesign your approach such that you stop actually doing any “long-term" running. That's a no-go. Jobs just have to run until they are done. There are dozens if not hundreds of pieces of data that are built and used along the way. Some of them are hogs that will run for 3 hours. How isolated are each of these jobs? For example, is progress being routed back to another thread or is all of the work contained to that thread? All the work for each job is pretty much self-contained in its thread as far as the SBApplication goes. Each job gathers data from the network, generates one of more InDesign documents and saved the resulting files of various types. They all communicate back to other servers by various means (simple "I'm still working" heartbeats), communicate with main parent app and various objects in the app to show progress, all of which has been heavily stressed and show no signs of causing problems. Swift has wormed its way into this fairly old Cocoa app, mostly in the data access from networks. Just mentioned that in case that adds its own demons. I'll also throw out that we've always been plagued with the odd "no result was returned" from scripts, and they all return a value. Sometimes this is reproducible when running on our servers, but not nearly as much when I run the same job on my Mac using InDesign Desktop instead of InDesignServer. I can't tell if it's the Adobe app that's failing to sometimes return the result from the script it runs, or the SB/AE world that fails. Again, mentioned in case it raises a flag.

That's interesting about the difference between NSOperation and NSThread as far as Mach ports go. I watched the # ports in Activity Monitor as I ran a job, and it certainly doesn't climb as each job runs. It goes from initially in the 300s to the low 500s right when the job starts, and stays around there, even after the job ends, and then I run the same job 2 few more times without quitting. This app can run for days or weeks. It can process anywhere from a few to probably a couple hundred jobs a day. Yes, each job creates a new NSOperation and a new SBApplication, which are both destroyed when each job finishes. Each job can call into the SBApplication hundreds or thousands of times. The rate at which each script is run can be as fast as possible, given the speed at which InDesignServer will process each script. At times there is barely any application code going on between each script. (E.g. ask InDesign for the range of some text, tell InDesign to do something with that range of text, tell InDesign to replace that range of text, etc, where each of those is a separate call to the doScript:language:withArguments:undoMode:undoName: method from InDesign's ScriptingBridge header file). I've added a 3rd crash log to the bug report, if it helps.

In your System Log post, this part has me confused: Console supports viewing log entries in a specific timeframe. By default it shows the last 5 minutes. To change this, select an item in the Showing popup menu in the pane divider. If you have a specific time range of interest, select Custom, enter that range, and click Apply. I'm not finding this pane divider popup, not as a visible control or as a contextual menu. Which pane divider? The Mac I'm looking on right now is sing macOS 26.3. My work one (not booted yet, but the one experiencing the problem for this thread) is 15.something.

I spent all day yesterday trying to make the error occur, but had no luck. Of course, when we need to get a job out the door for a customer, it pops up all the time.

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.

Hoo boy, making a sample app might be tricky. I'll find time to see if it's possible. Is there any way to know if the error is coming from OSA/SB or if InDesign is doing something goofy that would cause that error to be returned?