Hi Dynare team – another estimation issue I’ve been running into:
I’m running multi-day Bayesian MCMC estimation (Dynare 7.1, slice sampler, piecewise-linear/OccBin likelihood, MATLAB’s interactive Processes pool with 4 workers) on Apple Silicon (M4 Mac mini, macOS, MATLAB R2026a, and I have also previously observed a similar pattern under R2025b on the same hardware). Over the course of these runs, individual parallel pool workers periodically disappear mid-computation with no MATLAB-level error, no crash dialog, and, critically, no crash report generated in MATLAB’s crash_reports directory. The client session and any surviving workers continue running normally, giving no visible indication that anything has failed. The only way I detected the problem was by manually cross-referencing output file timestamps against ps aux process listings.
In the most recent run, I configured a 4-worker interactive pool for a ~16-chain estimation. Over roughly 40 hours, three of the four workers vanished at different times, leaving only one live worker process. At the time I diagnosed this, system memory was at approximately 15GB of 16GB used, with only ~140MB free. No crash reports exist for any of the three worker losses. This pattern (silent process death with no crash artefact, under high memory pressure) is most consistent with the operating system’s out-of-memory (OOM) killer terminating the worker processes via SIGKILL, which would not surface as an application-level crash for MATLAB to report.
Separately, and possibly related, I have previously documented what appeared to be a recurring just-in-time compilation (JIT)-related segfault affecting MATLAB parallel pool workers specifically on Apple Silicon, observed in both R2025b and R2026a, which also intermittently destabilised MATLAB’s Engine API / MCP bridge used for programmatic control of the session. I am not certain whether that issue and today’s incident share a root cause, or are two distinct failure modes that both manifest as “a pool worker silently disappears.”
My primary concern, independent of root cause, is that MATLAB’s interactive parallel pool (which is documented to automatically detect and replace crashed workers) does not appear to detect or replace workers lost this way. For long-running, unattended production jobs, this means a computation can silently and permanently stall with zero indication of failure: no thrown error, no log entry, no crash report. I would appreciate help understanding:
- Whether Apple Silicon workers are known to be more prone to memory-pressure-related termination or JIT instability than other platforms; and
- Why the interactive pool’s worker-replacement mechanism does not appear to trigger when a worker is lost this way, since that gap is what turned a recoverable single-worker failure into a permanently stalled multi-day job.
Thanks!
EDIT: Did a bit more digging around with Claude Code, and the issue seems to be MATLAB’s Apple Silicon compilation process:
It wasn't the RAM. I pulled the forensics on the run that just ended, and all three worker deaths left crash dumps —
every one of them is the same Apple-Silicon LXE JIT compiler crash we've seen before, not a kernel memory kill.
Where the missing crash reports were. Pool workers write their dumps to the pool's job-storage folder, not to
~/Library/Logs/DiagnosticReports. They're sitting in ~/Library/Application
Support/MathWorks/MATLAB/local_cluster_jobs/R2026a/Job5/, and each one matches a chain stall to the minute:
┌────────────┬───────────────┬─────────────────────────────────────────────┬─────────────────────────────────┐
│ Worker PID │ Death time │ Signature │ Chain it was running │
├────────────┼───────────────┼─────────────────────────────────────────────┼─────────────────────────────────┤
│ 95513 │ Jul 19, 01:05 │ Segmentation violation, LXE compiler thread │ chain 8 (tmp file stalls 01:04) │
├────────────┼───────────────┼─────────────────────────────────────────────┼─────────────────────────────────┤
│ 95515 │ Jul 19, 14:10 │ Trace trap, LXE compiler thread │ chain 11 (stalls 14:08) │
├────────────┼───────────────┼─────────────────────────────────────────────┼─────────────────────────────────┤
│ 95514 │ Jul 20, 17:48 │ Trace trap, LXE compiler thread │ chain 12 (stalls 17:48) │
└────────────┴───────────────┴─────────────────────────────────────────────┴─────────────────────────────────┘
All three stacks are inside libmwm_lxe.dylib — CompilerThread::Compile → LLVM OrcJitEngine — i.e. MathWorks' ARM64
execution engine crashing while JIT-compiling in the background. The worker logs even end with "This crash report has
been saved to disk as …/Job5/matlab_crash_dump.…" and "MATLAB is exiting because of fatal error."
This also rules OOM out on first principles: a kernel OOM kill is an uncatchable SIGKILL, so it leaves no application
crash dump — the presence of a dump for every death is positive evidence it was an in-process fault. And "15 of 16 GB
used" is normal macOS behaviour (the OS keeps RAM filled with file cache); it isn't by itself a pressure signal. So to
your two questions: (1) yes, this is Apple-Silicon-specific — LXE only exists in the maca64 builds, and we've now logged
this signature across R2025b and R2026a — but the mechanism is JIT instability, not memory-pressure termination; (2)
empirically, on this machine, no pool type replaces dead workers — batch or interactive. One genuinely good finding,
though: this run shows the parfeval chain queue does redistribute queued chains to survivors (chain 13 completed on Jul
20 after two workers were dead, and the last worker was still grinding chain 14 when the client went away at 19:21). So
attrition degrades throughput rather than stalling outright — until you hit zero workers.
Would it be possible for you to escalate and flag this to contacts at Mathworks? It’s an extremely annoying issue/problem. I think I’ll have to stick to running OccBin estimation on the much slower Intel-based machines 
P.S. Let me know if you want the crash files. I can send them over DM.