Recurring native crash (SIGSEGV / EXCEPTION_ACCESS_VIOLATION) in torq::seal_napi::Context, UXP webview plugin

Photoshop UXP Plugin API
, ,
1

Hi everyone – hoping to tap into the community’s experience on a tricky one we’ve been chasing for a while.
Our UXP plugin’s main UI runs inside a <webview> panel element, talking to the host/panel JS context (where require("photoshop") runs) via Comlink over postMessage – all native Photoshop calls (executeAsModal, imaging.getPixels, etc.) are dispatched async from the webview this way. We’re seeing Photoshop itself crash natively, on both macOS and Windows, across several users. 8+ crash reports collected so far, at least 3 distinct stack shapes, all bottoming out in the same component.

The crashes are not consistent or frequent – they happen rarely, at an arbitrary point in a session, not tied to a specific reproducible click or sequence we’ve been able to pin down (see “What we’ve ruled out” below).

Crash A (macOS)

Thread Third Party - UXP JavaScript Thread:

napi_pump_message_loop → torq::seal_napi::Context::runDelayedTasks()
→ dynamic-torqnative dispatch tail

EXC_BAD_ACCESS (SIGSEGV). Same frame offsets across multiple independent reports.

Crash B (macOS)

Crashes on the Main Thread, inside AppKit’s own event dispatch:

-[NSApplication _handleEvent:] → ~28 frames deep in dynamic-torqnative
(recursive pattern, offsets repeating) → torq::seal_napi::Context::protect-family

EXC_BAD_ACCESS, KERN_INVALID_ADDRESS at 0x58 (byte read from a null/near-null pointer + small offset). This report’s own kernel triage hint: VM - (arg = 0x3) mach_vm_allocate_kernel failed within call to vm_map_enter.

Crash C (Windows)

napi_unwrap → torq::seal_napi::Context::protect

EXCEPTION_ACCESS_VIOLATION (0xc0000005), RCX = 0x0 at the crash site (null pointer in the first-arg register).

What we think is going on

All three land in torq::seal_napi::Context, and all three fault at small fixed offsets from a null/near-null pointer. napi_unwrap is standard N-API – per spec, calling it on an unwrapped/already-unwrapped object returns an error status, it doesn’t crash. A hard crash inside it suggests either upstream heap corruption, or a thread/isolate-affinity violation.

This looks like the same shape as an existing thread: Photoshop 2025 crashes with WASM-based plugins – identical napi_unwrap → torq::seal_napi::Context::protect / 0xc0000005 shape. An Adobe UXP team member replied there:

“Currently, our UXP team does not test or officially support WASM. It’s possible that recent updates, such as the V8 upgrade, have further impacted the functionality”

and the working diagnosis in that thread was async instantiation racing the NAPI layer (“concurrent memory access violations”), fixed by forcing synchronous compilation instead of async. We don’t use WASM, but our whole plugin is async-by-design (webview – host via Comlink/postMessage for every native call) – if async-vs-NAPI races are a known general hazard and not WASM-specific, that would fit what we’re seeing.

What we’ve ruled out

Stress-tested several hypotheses with real Comlink/native calls (not mocks), across multiple machines, both OSes – none reproduced a crash on their own or combined:

  • A host-side native call (unrelated <webview> focus/blur, not serialized against our imaging queue) racing an active executeAsModal/getPixels call – thousands of iterations, no crash (did find a real but non-fatal side effect: intermittent “host is in a modal state” rejections).
  • Capturing immediately after a plugin reload (cold start / not-yet-settled Comlink handshake).
  • Deliberate memory pressure (~2GB+ held) during large captures.
  • Combined GPU load + screen-recording software + memory pressure, on a separate machine.

Environment

  • Photoshop 27.8.0 (macOS reports), 27.9.1 (Windows report).
  • <webview> panel.
  • Crashes cluster around actions that call executeAsModal + imaging.getPixels().
  • One report: screen-recording software active, 32GB RAM, macOS.
  • One report: hybrid GPU (discrete NVIDIA + integrated AMD), Windows.

Asking

  1. Is this the same “concurrent memory access violations in the NAPI layer” class as the WASM thread, just triggered by async webview–host Comlink calls instead of async WASM instantiation?
  2. Any guidance on which async patterns are safe vs. unsafe against the NAPI bridge?
  3. Could an un-serialized host call (e.g. a DOM focus operation on the <webview> element) racing an active executeAsModal cross JS-engine thread/isolate affinity internally?
  4. Any defensive pattern for large getPixels()/getData() calls under memory pressure?

Also just genuinely asking the community here: if anyone has run into anything similar with a webview-based UXP plugin, or has a hunch about where else to look, we’d appreciate any pointer – at this point we’re open to any direction.

Happy to share the full crash reports on request. We don’t have a reliable repro case – we’ve built and run several stress-test harnesses targeting the hypotheses above (thousands of iterations, multiple machines), but none of them have triggered the crash themselves.