Skip to content

fix(emboss): raise worker thread stack to 256MB to survive CGAL exact-arithmetic text-cut (macOS SIGBUS)#559

Open
Jcapehart2 wants to merge 2 commits into
Snapmaker:mainfrom
Jcapehart2:fix/emboss-stack-size
Open

fix(emboss): raise worker thread stack to 256MB to survive CGAL exact-arithmetic text-cut (macOS SIGBUS)#559
Jcapehart2 wants to merge 2 commits into
Snapmaker:mainfrom
Jcapehart2:fix/emboss-stack-size

Conversation

@Jcapehart2

Copy link
Copy Markdown

Problem

The Emboss text tool's "On Surface" projection crashes hard (EXC_BAD_ACCESS / SIGBUS, KERN_PROTECTION_FAILURE) on macOS, especially Apple Silicon. It reproduces while adding, moving, or slicing surface-projected text, and is non-deterministic (depends on exact placement).

Root cause (diagnosed from crash dumps)

"On Surface" runs CGAL::Polygon_mesh_processing::corefine. On near-degenerate inputs (thin font stems, coplanar slivers where glyphs meet a curved wall) CGAL's filtered predicates fall back to exact rational arithmetic (GMP mpq), which recurses deeply. The faulting thread always dies inside GMP primitives:

EXC_BAD_ACCESS (SIGBUS, KERN_PROTECTION_FAILURE) at the stack guard page
  __gmpn_sub_n / __gmpn_lshift / __gmpn_rshift
  __gmpz_sub / __gmpz_gcd
  __gmpq_aors

The worker thread's stack overflows into its guard page. create_thread() in src/libslic3r/Thread.hpp sets only 4 MB here (the value still shipping in Snapmaker Orca 2.3.4).

Verified on a Mac mini M4 / macOS 15.5: a clean, watertight 214k-triangle model (0 non-manifold edges) consumed the entire stack and hit the guard. Note: even the upstream 16 MB bump (OrcaSlicer#13772) was observed to still overflow on real-world models — the crash report showed the full 16 MB stack region consumed. It works on Linux/Windows because the exact-arithmetic fallback is rounding-dependent and typically isn't taken there.

Fix

Raise the worker-thread stack in create_thread() to 256 MB. macOS and Linux reserve thread stacks but commit pages lazily, so idle workers cost address space, not RAM — only a thread that actually recurses deeply commits real memory.

Test

  • Repro: open a curved model, Text tool → enable On Surface, place/move text → crash on affected builds.
  • With this patch: the same operation completes without the guard-page fault.

…-arithmetic text-cut

The Emboss "On Surface" path calls CGAL corefine, which falls back to exact
GMP rational arithmetic on near-degenerate inputs and recurses deeply. The 4MB
stack (Snapmaker 2.3.4) overflows the guard page -> SIGBUS in __gmpn_*/__gmpz_gcd
on macOS arm64. Even the 16MB upstream bump (PR OrcaSlicer#13772) still overflows on real
models (verified: a clean 214k-tri cooler consumed the full 16MB stack). Reserve
256MB; thread-stack pages are committed lazily so idle workers cost address space,
not RAM.
…heap over-read

The Emboss 'On Surface' cut_surface path crashes on macOS/arm64 with EXC_BAD_ACCESS
inside CGAL corefinement's exact (Epeck) constrained triangulation (insert_constraint
-> Compare_along_axis -> __gmpz_mul reads past a heap buffer). Snapmaker 2.3.4 pins
CGAL 5.4 (2022); mainline OrcaSlicer already uses 5.6.3, which is API-compatible with
this Emboss/CutSurface code and carries ~1.5y of PMP/corefinement fixes. Drop the
5.4-only clang19 patch (does not apply to 5.6.3).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant