Fix two macOS crashes: lld exception unwinding in executables, and payload-less segments aborting the app

[JamesDarby345]

Two crashes hit while building and running VC3D from source natively on macOS (Apple Silicon, Homebrew LLVM). Both abort the process with an uncaught exception that a handler already in the code should have caught. They're independent and split into one commit each, so either can be dropped.

1. ld64.lld breaks exception unwinding in executables

Symptom — opening any volume package:

libc++abi: terminating due to uncaught exception of type std::runtime_error:
Active volume is not loaded for Lasagna shape pairing

Why it throws at all, and why that's fine. CState::setVpkg emits before a volume is loaded, so CWindow::updateAtlasFiberDocks calls resolveLasagnaForVolume with an id that isn't in loadedVolumes_ yet. It throws. That's an expected condition on every project open, and the catch (...) in updateAtlasFiberDocks exists precisely to swallow it.

Why it aborts. It never reaches that handler. From the crash report:

 8 libc++abi   __cxa_throw
 9 VC3D        vc3d::opendata::resolveLasagnaForVolume(...)
10 VC3D        (anonymous namespace)::resolvedLasagnaForState(CState const*)
11 VC3D        CWindow::updateAtlasFiberDocks()::$_1::operator()() const   <-- catch (...) is here
12 VC3D        CWindow::updateAtlasFiberDocks()
...
 7 libc++abi   __cxxabiv1::failed_throw(...)
 6 libc++abi   std::__terminate(void (*)())

failed_throw means unwinding found no handler, with the handler plainly on the stack.

CMakeLists.txt already documents this exact ld64.lld defect and works around it — but only for SHARED_LIBRARY targets, since it was first observed for cross-dylib throws. With Homebrew clang/lld 22.1.8 the same corruption occurs within the VC3D executable, which stays on lld.

Evidence — same objects, same dylibs, only the executable link changed:

Linker	Volume-less project	Malformed project
ld64.lld 22.1.8	SIGABRT	SIGABRT
Apple ld	handled, runs	handled: "Cannot open project", exit 2

The fix extends the existing workaround to all targets. Trade-off: some macOS link time for exceptions that work. CI doesn't catch it because it pins an older dependency set whose lld still linked executables correctly — worth knowing that the pin is currently load-bearing.

2. A segment with no tifxyz payload aborts the app

Symptom — after a partially completed Open Data sample download, clicking Reload Surfaces:

libc++abi: terminating due to uncaught exception of type std::runtime_error:
Failed to open TIFF: .../remote_cache/open_data/segments/.../x.tif

The cache held meta.json + catalog-origin.json for 15 segments but payload for only one.

Cause. Segmentation::canLoadSurface() only checks format == "tifxyz", so a payload-less directory registers as a usable surface. loadSurface() returns a QuadSurface whose TIFFs are read lazily by ensureLoaded() on first geometry access — long after loadSurface()'s try/catch has returned. That first access lands inside a Qt slot:

SurfacePanelController::loadSurfacesIncremental
  -> CState::setSurface -> [signal] -> onSurfaceChanged
  -> updateFocusMarker -> volumeToScene -> QuadSurface::pointTo
  -> ensureLoaded -> load_quad_from_tifxyz -> throw

Nothing in that chain catches. The identical error is already survivable one frame over — ViewerManager's SurfacePatchIndex task wraps its call and logs single-surface task failed — which is why one segment logs a warning and the next one kills the session.

Fix, two layers:

• Prevention — canLoadSurface() also requires x/y/z.tif to exist. An incomplete directory is simply not loadable, keeping the failure at registration time where loadSurface() already returns nullptr and callers handle it.
• Containment — onSurfaceChanged() becomes a thin guard around onSurfaceChangedImpl(), so a payload that goes missing after registration (deleted mid-session, corrupt TIFF, unmounted share) logs and skips the surface.

Why the guard is inside the slot rather than a global net. I first implemented containment as a QApplication::notify() override, the usual approach. It cannot work: exceptions don't propagate through Qt's dispatch frames. With a throwing QObject::event:

Frames between throw and catch	Result
Ours only	caught
QtCore (sendEvent)	terminate
QtWidgets (notify)	terminate

The crash report showed VCApplication::notify on the stack with its try active while the throw terminated inside QtWidgets frames below it. So that approach was dropped. Practical implication for this codebase: a catch placed above a Qt frame is decoration — containment must happen before control returns to Qt, which is what the existing ViewerManager / LineAnnotationController handlers already do.

Testing

• test_segmentation: 13/13, including new cases for missing and partial payloads.
• Project with a payload-less segment: reports Loaded 0/1 ... Missing: <id> and keeps running (previously SIGABRT).
• Project with unreadable TIFFs: surface skipped, app runs.
• Full suite: 111/113. test_volume_pkg_full (volume attachment) and fiber_save_batch_tracker::emptyBatchCompletes fail — verified pre-existing by stashing these changes, rebuilding clean, and reproducing both.

For review

A segment directory that exists before its TIFFs are written — a tracer mid-run — is now skipped until complete rather than registered early. The incremental reload picks it up once written, but that's the intentional behavior change most worth a second opinion.

🤖 Generated with Claude Code

[vercel]

@JamesDarby345 is attempting to deploy a commit to the scroll Team on Vercel.

A member of the Team first needs to authorize it.

[JamesDarby345]

Review by launching the VC3D app and loading a data volume successfully; these fixes target doing that natively on macOS