Skip to main content
gunterl70469068
Inspiring
August 12, 2026
Question

Intermittent EXC_BAD_ACCESS in VulcanMsgRecv thread (dynamic_cast on freed object) on quit — InDesign 2026 (21.5.1.73), C++ SDK plugin

  • August 12, 2026
  • 1 reply
  • 22 views

We're seeing an intermittent crash when quitting InDesign 2026 (v21.5.1.73, macOS 26.5.2, Apple Silicon) while our C++ SDK plugin is loaded. The crash occurs on the VulcanMsgRecv thread, inside a dynamic_cast in VulcanMessage5.dylib, apparently operating on a freed/invalid object (KERN_INVALID_ADDRESS, guard-pattern address).

 

Two independent crash reports, captured on different days, show byte-identical offsets into VulcanMessage5.dylib (only the ASLR base differs), indicating this is a single deterministic code path rather than a generic timing race:

 

Crash 1 (2026-08-11): base 0x1028cc000

Crash 2 (2026-08-10): base 0x107784000

Both crashes, same relative offsets:

0 libc++abi.dylib __cxxabiv1::...dyn_cast_get_derived_info + 8
1 libc++abi.dylib __dynamic_cast + 56
2 VulcanMessage5.dylib +101896
3 VulcanMessage5.dylib +100392
4 VulcanMessage5.dylib +101640
5 VulcanMessage5.dylib +100344
6 VulcanMessage5.dylib +105948
7 VulcanMessage5.dylib +104900
8 VulcanMessage5.dylib +104728
9 VulcanMessage5.dylib +68136
10 VulcanMessage5.dylib +65580
11 VulcanMessage5.dylib +114372
12 VulcanMessage5.dylib +245924

Exception: EXC_BAD_ACCESS (SIGSEGV), KERN_INVALID_ADDRESS, triggered on thread VulcanMsgRecv.

 

What we've ruled out on our side (plugin does not directly use Vulcan):

  • Plugin source contains no references to VulcanMessage, VulcanScriptProvider, or ExtendScript (confirmed via source grep).
  • Plugin's shutdown boss (IStartupShutdownService::Shutdown()) properly joins all background worker threads (via std::thread::join()) before releasing plugin state; worker threads never call InDesign SDK functions directly.
  • Plugin's IObserver-derived doc observer is properly detached (AutoDetach/base class handling) — not left dangling.
  • Reproduced quitting under multiple conditions: no dialogs opened, only our custom Preferences (selectable/switcher-based) dialog opened and closed, only our modal dialogs opened and closed, and with documents that had links placed/relinked — none of these targeted tests reproduced the crash on demand, consistent with it being rare/intermittent rather than tied to one obvious user action.
  • VulcanMessage5.dylib in the shipped app bundle is stripped, so we're unable to symbolicate the offsets ourselves (atos returns only the same numeric offsets).

Since we don't use Vulcan APIs directly, we suspect this is either (a) an internal Adobe subsystem (Links panel status broadcast, CC Libraries, font sync, or similar) racing with app-quit teardown, possibly triggered indirectly by plugin-driven document/link activity, or (b) a shutdown-ordering regression in VulcanMessage5.dylib itself. Given the matching offsets across sessions, this looks like a specific, fixable code path rather than a diffuse timing issue. Could someone with symbols for VulcanMessage5.dylib map these offsets to source, or advise whether this matches a known internal bug?

 

I attached the full crash reports (*.ips) renamed to *.txt.

 

Best regards

Gunter

    1 reply

    MelJ247
    Participant
    September 13, 2026

    Hi Gunter,

     

    I have one possible lead: a CEP (.zxp) extension, not an SDK plug-in

    I hit what looks like your exact crash and it stopped after I removed a CEP extension, so I wanted to add my data point.

    My setup: InDesign 2026, 21.5.1.73. macOS 26.6.2 (25G83), Apple Silicon (Mac16,7). Crash at quit, thread named VulcanMsgRecv, EXC_BAD_ACCESS inside __dynamic_cast called from VulcanMessage5.dylib. My report has the same twelve offsets you listed — +101896, +100392, +101640, +100344, +105948, +104900, +104728, +68136, +65580, +114372, +245924 — so I believe it's the same code path.

    The difference from your case: I have no custom C++ SDK plug-in at all. Every binary in my image list is Adobe's own, from inside the app bundle. What I did have was one CEP extension installed as a .zxp — Multi-Find/Change from Automatication — sitting in /Library/Application Support/Adobe/CEP/extensions. I had no per-user CEP folder. Worth noting the vendor lists that product as supporting InDesign/InCopy 2020–2025, and I'm on 2026.

    Because a .zxp extension is web code rather than a compiled plug-in, it never appears in the loaded-binary list in the crash report. I nearly ruled it out on that basis, which is why I'm flagging it: the report can look clean of third-party code while an extension is still active. My crash log also showed the CEP host (PlugPlugOwl) with a thread waiting on a main thread that was already inside exit().

    I moved that extension folder out of the CEP extensions folder and restarted. Then ten launch-and-quit cycles, including saving a new document, closing a template without saving, and placing a story and saving it. No crashes. I'd been getting this intermittently for four or five years, across different InDesign versions and different computers, which is what makes me think the extension was the constant rather than any one build.

    If you or anyone else on this thread has any .zxp extension installed, it's a cheap test to just move the folder out of /Library/Application Support/Adobe/CEP/extensions , see if that fixes it.

     

    Hope this is helpful,

    MelJ247

    Terms & ConditionsAccessibility statement
    Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices