* fix: prevent heap corruption in model repair with auto-backup
The CGAL model repair (fix_model_with_cgal_gui) runs on a worker thread
that mutates the live ModelObject (split / delete_volume / set_mesh).
Those mutators transitively call save_object_mesh(), which hands the
object to the auto-backup manager. The manager clones and serializes the
object on its own thread via an internal Model documented as "visit only
in main thread". Running that path from the repair worker races the
backup thread on the shared model, causing use-after-free / heap
corruption -- EXC_BAD_ACCESS and libmalloc "corruption of free block"
aborts, always with the "cgal_fix_model" worker on the stack inside
add_object_mesh -> Model::add_object / delete_object.
Wrap the repair in a SaveObjectGaurd so the backup manager ignores the
object for the duration of the repair; a single backup is taken when the
guard is released on the main thread after the worker joins. This mirrors
existing batch-edit usage of SaveObjectGaurd (Model.hpp, GUI_ObjectList).
Repro: repair a multi-part / splittable object with auto-backup enabled
(Preferences > Backup); crashed within a few repairs on macOS arm64.
* Update FixModelByCgal.cpp
---------
Co-authored-by: Ian Bassi <ian.bassi@outlook.com>
* build: add build_win.bat, a Windows build script for deps, slicer and toolchain setup
build_release_vs.bat takes no options: what it builds is decided by editing
it. This adds build_win.bat alongside it, with short and long options, a
grouped help message, a dry-run mode that prints every command instead of
running it, and one option per thing a developer actually varies - the
configuration, the architecture, the compiler, the generator, the Visual
Studio release, how much gets rebuilt, and where the dependency tree lives.
It works from any directory, needs no developer command prompt in either
generator mode, and keeps CMake ahead of Strawberry Perl on PATH so a build
does not depend on how the user ordered their environment.
scripts/test_build_win.ps1 covers it with table-driven cases that run the
script under --dry-run and assert on the commands it prints, so nothing is
configured or built. The Windows build jobs wait on that suite.
Based on the script from OrcaSlicer#11097.
Co-authored-by: Ocraftyone <24759591+Ocraftyone@users.noreply.github.com>
* build: report what build_win.bat produced and what to do next
Every successful run now ends with a block naming what it built and the
commands to carry on with. Those commands repeat the flags that reproduce
the run, so a rebuild after a clang-cl Ninja build is not silently an MSVC
one. A failure gets a framed block naming the command that failed and a
retry scoped to the stage that failed, so a slicer error does not suggest
discarding an untouched dependency tree.
Installing is now opt-in behind -i. The install tree is a second full copy
of the build that exists mainly so the release can be zipped from it, while
the build tree is already runnable, with the DLLs beside the binary and
resources symlinked rather than copied.
Configuring against a dependency tree that was never built now names it
instead of failing several hundred lines into CMake's package resolution.
scripts/test_build_win.ps1 covers all of it, and gains -Name so one case
can be run without the full pass.
* build: let the test options stand alone, and say which build things apply to
--run-tests named two things to do and then did neither without -s, so
`build_win.bat -lx --run-tests` answered "Nothing to do". Both test
options now imply the slicer build they cannot happen without, unless
another action was already named, so -d --tests is still a dependency
build. --install-vs has turned on --install-deps the same way all along.
That makes them actions, so they move to the group that says so. -i goes
the other way, to the step toggles beside --no-configure and --no-gettext,
since it does not stand alone and adds a step rather than describing what
kind of build to make. An example shows the tests run with toolchain
flags, because flags pick which build gets tested and a bare --run-tests
would build and test a default tree the developer never asked for.
Two help lines named defaults that were not the defaults. --build-dir said
"instead of build/" and --deps-dir said "instead of deps/", but trees are
named for the configuration, compiler and architecture, so build/ is only
the default for a release x64 MSVC build, and deps/ is the source
directory rather than a tree anything is built in.
The hint for a missing dependency tree now carries the flags that
reproduce the run. It said "Build them with -d", which after a clang build
points at the MSVC tree, so following it left you no better off. Every
other suggestion the script makes already repeats them.
-k counted on the developer to read taskkill invocations as progress. It
now names each image and how many processes it is about to stop, which is
what explains the pause, and skips the ones that are not running instead
of printing taskkill's "not found" as though something had gone wrong. No
image can stop the rest.
The environment example set SLIC3R_ASAN, which -a already does, teaching
the long way round to a flag the script owns. It now sets options that
have no flag. The note under it said "Use these for a value containing
spaces. Ampersands are not supported", which named neither what "these"
were an alternative to nor where ampersands were a problem.
The test harness gains a NotExists field, because output cannot show what
a run did not create, and two cases needed to prove exactly that.
---------
Co-authored-by: Ocraftyone <24759591+Ocraftyone@users.noreply.github.com>
Co-authored-by: Rodrigo Faselli <162915171+RF47@users.noreply.github.com>
* ci: build the Windows x64 dependencies and slicer with clang-cl
Passes -l -x from the Windows jobs, using the clang-cl and Ninja options
added in #15373. Ninja runs each dependency's build step as a plain command,
so the jobs set up a VC environment for OpenSSL's nmake. arm64 stays on MSVC
for now.
The deps cache key gains the compiler, so windows-x64 becomes
windows-x64-clang and windows-arm64 becomes windows-arm64-msvc.
* deps: select OpenSSL's ARM64 target from DEPS_ARCH
CMAKE_GENERATOR_PLATFORM is only set by -A, which Ninja never receives, so
the Ninja build selected the x64 target on ARM64. DEPS_ARCH is derived from
CMAKE_SYSTEM_PROCESSOR and is already independent of the generator.
* ci: build the Windows ARM64 dependencies and slicer with clang-cl
Three dependencies need handling first. libpng and OpenCV each build an ARM
SIMD path that does not compile with clang-cl, so those paths are off; PNG
already had the same opt-out for Apple ARM. OCCT is built with cl, since
clang-cl cannot emit one of its large generated files and there is no option
to turn that off. All three are gated to Windows ARM64 with clang.
The rows, their ✗ buttons and the click-to-highlight were all built against
m_doc.features[m_constrain_feat].entity_constraints — a COMMITTED feature. A live sketch
has no committed feature, so the card was hidden for the whole session and the list it
would have shown was empty by construction. Every constraint applied while drawing was
nameless: the badge said one existed, nothing said which.
rebuild_constraint_list now picks its source by scope. live_constraint_scope() is the same
discriminator apply_constraint already used to route to apply_live_constraint — both
Constrain modes set m_active, so is_sketching() alone would claim the live scope while the
committed manager is open. delete_constraint and highlight_constraint_entities branch on
it too, and the card shows in Sketch mode as well as Constrain.
Keeping the rows in step needed a signal that did not exist: on_solve_state fires on every
frame of a drag, so rebuilding from it would rebuild the list continuously. The tool now
fires on_constraints_changed only when the constraint SET changes — one added by
try_add_constraints, one removed by remove_constraint (the indexed form the badge click and
the ✗ row now share).
The rebuild is deferred through CallAfter. One of its callers is the ✗ button's own click
handler, and rebuild_constraint_list destroys those buttons: deleting the window whose
handler is still on the stack is a use-after-free.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011FbJKJAJxxkhDTs9XdZzKA
A glyph reads as decoration until something says otherwise, so the badges shipped
last commit were discoverable only by accident. Two places now say it, chosen because
they are where the eye already is:
- the moment of applying, which is the one the user is watching ("Applied constraint ·
its badge is on the sketch — click the badge to remove it"). The hint line could not
carry this alone: it only refreshes when the (mode, step, picks) tuple changes, and
applying a constraint changes none of them.
- the Select-mode hint line, appended only while the live sketch actually holds a
constraint, so it never advertises a badge that is not on screen.
Also fixes what the previous commit got wrong: remove_constraint_near solved through
solve_sketch_entities directly, which relaxes the geometry but leaves m_dof and the
per-entity conflict flags untouched and never fires on_solve_state. Deleting a
constraint therefore left the DoF readout describing the system as it was BEFORE the
deletion, and any red over-constrained tint stranded on screen. It goes through
resolve_live() now, the same path every other live edit uses.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011FbJKJAJxxkhDTs9XdZzKA
The constraint badges existed and had never once been drawn where they were needed.
build_constraint_glyphs read m_constrain_cons, a vector only the COMMITTED-feature
Constrain mode fills, and the draw call sat inside `if (m_mode == Mode::Constrain)`.
Every constraint applied during a live sketch — which is the path the Constrain buttons
take while drawing, the one added in "Constrain while you sketch" — went into
m_constraints and was rendered by nothing. You could not see that Parallel had applied,
so "nothing happens" was indistinguishable from "applied and invisible".
The glyph builder now takes its constraint list as a parameter: Constrain mode passes
m_constrain_cons as before, the live session passes its own m_constraints. Same glyphs,
same teal.
Seeing them is half of it. A constraint's entire state is exists / does not exist, so the
toggle is a delete, and there was no way to reach one during a session — the ✗ rows in
the panel list are bound to the committed feature. Each badge now records where it landed
(m_glyph_hits) and a plain left click in Select mode within its cell drops that constraint
and re-solves. Shift/Ctrl clicks are left alone so multi-select still works.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011FbJKJAJxxkhDTs9XdZzKA
Two reports, one root: the sketch tab could not show what was selected.
The bed grid landed last commit, and selection was painted pure white — a freshly
drawn line is auto-selected by the creation tool, so the first thing a new line did
was disappear into the grid. Selection now wears design_selection_color(), the same
cyan a picked solid already wears. White is kept for the hover handle alone.
That invisibility is also why "I apply Parallel and NOTHING HAPPENS": drawing two
lines leaves exactly ONE selected (the last), Parallel needs two, so the planner
correctly refused — but the status text named only the requirement, never the current
pick, which reads as a dead button. It now reports how many are selected and how to
pick the second.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011FbJKJAJxxkhDTs9XdZzKA
Lam Wei Lun