Living quality record · memory & resource safety
Memory behavior is a maintained build-system contract.
Nift has short CLI commands, parallel builds and a genuinely long-running watch mode, so memory testing has to cover more than “the process exits cleanly once”. This page is the maintained record for leak, lifetime and resource-growth testing. It will be updated as campaigns are rerun rather than frozen as a launch-day claim.
Nift now has committed ASan/LSan/UBSan build targets, a fast memory-safety smoke gate, common JSON evidence output, peak-RSS capture and a Valgrind-compatible wrapper. End-to-end Nift lifecycle and watch-mode campaigns remain future checkpoints, so this does not yet claim a project-wide leak verdict.
The embedded parser now has a maintained one-process lifetime corpus covering parse/dump, malformed partial-allocation cleanup, mutation, copy/move ownership, deep/large JSON, streaming and early-stop paths. On 2026-08-18, 120 ASan + LSan + UBSan corpus iterations completed with zero findings; a separate 400-iteration RSS soak measured 10,624 KiB after warm-up, 10,688 KiB at midpoint and 10,688 KiB at completion. No production Jsonic++ source fix was required. Checkpoint 1B subsequently passed independently under Valgrind 3.26.0 on Linux at Jsonic++ commit b9d0ff3: 40 corpus iterations, 0 errors, 0 bytes in use at exit, all 6,579,515 allocations freed, and 215,992 KiB peak Valgrind process RSS. This completes the parser-component gate; it does not replace Nift's later end-to-end lifecycle, watch-mode and large-project memory checkpoints.
The standalone Minify++ component now has a maintained one-process multi-format lifetime corpus and batch CLI stress. At Minify++ commit db2a6ff, 80 ASan/LSan/UBSan corpus iterations completed with zero findings; a separate 300-iteration native soak stabilized at 7,160 KiB RSS from midpoint through completion after a 7,096 KiB warm-up observation. Sanitized CLI stress completed 8 × 42 files and a native CLI soak completed 30 × 70 files. No production Minify++ source change was required. Independent Checkpoint 2B confirmation subsequently passed on Linux x86-64 at Minify++ commit 2a51a38: Valgrind 3.26.0 ran 30 maintained lifetime-corpus iterations with 0 errors, 0 bytes in use at exit, all 2,448 allocations freed, and no leaks possible; peak Valgrind process RSS was 184,908 KiB. This completes the standalone Minify++ component gate. Nift-owned Minify++ lifecycle stress remains intentionally deferred to the cross-project integration checkpoint.
Checkpoint 3 exercised 57 sanitizer-backed core lifecycle/test phases: project creation and tracking mutations, copy/move/remove, successful builds, deliberate failures followed by repair, incremental modes, Project Contracts, JSON Schema, requirements, template-less tracking, Minify++ integration and cross-feature behavior. No ASan/LSan/UBSan finding surfaced. Checkpoint 4A then kept one native build-auto process alive for 180 deterministic successful invalidations across content, templates, contract data and schema-validated JSON. RSS stayed within 5,976–6,356 KiB, moving from 6,332 KiB after warm-up to 6,216 KiB at midpoint and 5,976 KiB at completion. A 100-cycle sanitizer watch run also completed without a sanitizer failure; its rising RSS is not interpreted as a leak signal because sanitizer quarantine changes allocator behavior.
The 10,000-page matrix remained below 12 MiB peak RSS across one, four and automatic worker counts, including a minified four-worker case. Full, no-op, single-page and shared-template rebuilds were all exercised. Checkpoint 4B is now complete on an external Linux host with Valgrind 3.26.0: the corrected acknowledgement-driven watch corpus completed all 30 cycles in 14.044 seconds at Nift commit 92e6c05, shut down through the intended SIGINT path, and the maintained harness returned PASS. The exact machine-readable evidence is retained with the source. Together with the native, sanitizer and 10,000-page evidence above, this closes Nift's watch/endurance checkpoint.
What matters for Nift
- Short-lived correctness: no ASan/LSan/UBSan findings during build, tracking, configuration, contracts, JSON/schema and failure paths.
- Repeated-build stability: thousands of build-updated/build-all cycles in one process where the command architecture permits it, plus scripted repeated invocations with memory telemetry.
- Watch-mode stability: long runs with file edits, creates, deletes, renames, failed builds and repairs while resident/heap growth is recorded.
- Concurrency: many-page and shared-dependency builds under multiple worker counts.
- Integrated components: Jsonic++ parsing and Minify++ final-artifact paths exercised as part of real Nift workloads.
- Large projects: 10k-page fixtures and shared-dependency invalidation used as operational memory-pressure cases, not only timing benchmarks.
Acceptance rule
No sanitizer or definite/indirect leak findings in the maintained workloads; no unexplained monotonic heap/RSS growth in long-running watch/soak tests after warm-up; failed builds must clean up without requiring process restart. RSS alone is not treated as a leak oracle because allocators may retain freed capacity.
Checkpoint plan
- Instrumentation baseline. Add reproducible ASan+LSan+UBSan configurations, Valgrind-compatible focused gates and machine-readable memory summaries.
- Core command lifecycle. Stress init/track/build/rm/mv/cp/list/config/error paths and retain any lifetime bug as a regression.
- Incremental/state lifecycle. Repeat modified/hash/hybrid invalidation, shared dependencies, Project Contracts, requirements and failed-build recovery.
- Watch endurance. Run sustained edit/create/delete/repair cycles and verify memory reaches a stable operating band.
- Parallel + 10k pressure. Repeat large builds and shared invalidations across worker counts, recording peak and settled memory.
- Integrated Jsonic++/Minify++ paths. Enable JSON/schema and minification-heavy projects so the embedded components are exercised under Nift ownership.
- Independent leak oracle + release gate. Cross-check focused Linux workloads under Valgrind, publish exact results here, and add the reproducible campaign to release-candidate validation.
How this page will be maintained
Each completed campaign should record date, commit, compiler/tool versions, workload duration/count, platform, peak/settled memory observations and any discovered regressions. A later code change can therefore invalidate or refresh evidence explicitly instead of inheriting an old “battle tested” badge forever.