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
Open
Conversation
…-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).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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 (GMPmpq), which recurses deeply. The faulting thread always dies inside GMP primitives:The worker thread's stack overflows into its guard page.
create_thread()insrc/libslic3r/Thread.hppsets 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