feat: bump upstream overlay pin to 6def7be9 (Bun merge-base) + glibc 2.44 free(NULL) fix - #276

The 6def7be9 pin bump's 2-level page-map rewrite (upstream d63979ae)
introduces a bug: the initial static page map's submap-0 entry is
NULL, and the release/unchecked lookup (_mi_unchecked_ptr_page)
indexes submaps[0][0] for p==NULL without a NULL check. glibc 2.44's
__newlocale calls free(NULL) from the loader before any constructor
runs; with MI_MALLOC_OVERRIDE that reaches mi_free and faults at
address 0 before main().

Import Bun's fix (oven-sh/mimalloc@942b8342, commit 7ac561ab, MIT):
point submaps[0] at a real zero-initialized submap instead of NULL, so
every lookup through the initial empty map safely yields no page.

Also imports test/test-free-before-init.c, registered as
test-free-before-init. It calls mi_free(NULL)/mi_malloc(64) from a
.preinit_array entry (the same point in startup as the glibc call) and
is linked against the static library specifically: the MI_OVERRIDE=ON
shared target compiles with MI_FREE_IS_CHECKED=1, which routes through
the NULL-safe _mi_checked_ptr_page and would never exercise the bug.
Verified RED before the fix (segfault) and GREEN after, locally.

MIMALLOC_FORKS.md pass-3 table gets two rows: this import, and a
correction -- #266 also called out a racy `prev_total == peak` compare
in stats.c's mi_stat_adjust_mt to drop when taking that file, but no
such compare exists in either 6def7be9's or Bun's stats.c; that part
of the issue was incorrect and no stats.c change was needed.

Refs #266

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YT4jVokb2gdT8ngFrH8i8S

Update the "Repo facts" pin note: 6def7be9 (was bcee5a88, was 579f8c0
before that), dated and reasoned per #264/#266 (Bun parity).

Refs #266

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YT4jVokb2gdT8ngFrH8i8S

Regenerate rust/mimalloc-pprof/vendor/* via `cargo run -p xtask --
amalgamate-c` and `amalgamate-h` against the 6def7be9 overlay bump
(#266). `cargo run -p xtask -- check` confirms the vendored copy now
matches src/include; `cargo build --workspace` and
`cargo test -p mimalloc-pprof` both pass.

Refs #266

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YT4jVokb2gdT8ngFrH8i8S

test-free-before-init.c's pre-init hook is GCC/Clang-only
(__attribute__((section)) / __attribute__((constructor))); pure MSVC
(cl.exe) defines neither, so the test would fail because the hook
never ran, not because of the bug it's meant to catch. Exclude it on
MSVC in CMakeLists.txt (MinGW/GCC is unaffected and still runs it via
the constructor branch); unverified on MSVC.

Also: fix a stale comment in src/threadlocal.c claiming the TLS slot
array is freed with plain mi_free -- it's actually freed with
_mi_meta_free(_mi_subproc(), tls, tls->memid), matching the meta
provenance the allocation now has. And drop the now-dead
src/arena-meta.c entry from ci/check_internal_state.py's EXCLUDED set
(the file was removed by the pin bump).

Refs #266

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YT4jVokb2gdT8ngFrH8i8S

Commit 326a38f's carry-forward of a fork MinGW-detection patch was
wrong. At bcee5a88 upstream tested `defined(__GCC__)`, a real typo (no
compiler defines that macro). But at the new pin (6def7be9) upstream
already reads `#elif defined(__MINGW32__)` in all three
MI_WIN_INIT_USE_* blocks -- `__MINGW32__` is a real macro, defined by
MinGW-w64 GCC (both 32- and 64-bit) and by clang targeting
`*-w64-mingw32`. Between our previous pin and this one, upstream fixed
the typo twice: `4cca633e`/`b5fdee4a` ("fix mingw detection: __GCC__ ->
__GNUC__") and then `1cf88691` ("use __MINGW32__ to detect mingw ...
instead of __GNUC__"). So our overwrite to
`defined(__GNUC__) && !defined(_MSC_VER)` was a no-op divergence with a
false rationale in its comment (and in 326a38f's commit message) --
and it is actually broader than upstream's fix, since it is also true
for Cygwin GCC, which is not MinGW.

No `x86_64-w64-mingw32-gcc` available in this environment to verify
`-dM -E` directly; the macro's definition by MinGW-w64 is documented
upstream (mingw-w64 predefined macros) and confirmed by upstream's own
commit history performing exactly this __GNUC__ -> __MINGW32__
narrowing for the same reason (avoiding false positives on Cygwin/
other GCC targets).

Fix: `src/prim/windows/prim.c` restored to `git show
6def7be9:src/prim/windows/prim.c` verbatim (0 diff). Also updates the
MIMALLOC_FORKS.md `mleak` row, which still described this as "this
fork's MinGW fix" (it is upstream-native as of this pin), and adds a
dated note to docs/upstreaming.md's MinGW section pointing at the
upstream fix commits, while leaving the historical `1f06f694`
measurements in place as an accurate record of their time.

Refs #266

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YT4jVokb2gdT8ngFrH8i8S

Commit 326a38f re-commented `mi_theap_collect_full_pages` and
restored the old fork call-site guard, citing the #128 B2/C1
measurement taken at our OLD pin (bcee5a88). But upstream `bf054991`
ENABLED this function between the pins, and re-disabling it on stale
evidence forks an upstream file's behavior without new justification.
Decision: take upstream's behavior at this pin.

`src/page.c` restored to match `git show 6def7be9:src/page.c` for
`mi_theap_collect_full_pages` and its call site in
`_mi_theap_collect_retired`. Every other fork hook in the file is
untouched -- diffed against 6def7be9 afterward, the only remaining
delta is the genuine `_mi_prof_on_free_collect` hook in the free-list
collection helper (unrelated to this function).

Verified safe:
- test-degenerate (the leak detector): PASSED, Release/MI_PPROF=ON
  and Debug/MI_DEBUG_FULL=ON.
- Full ctest, Release/MI_PPROF=ON: 25/25 passed.
- Full ctest, Debug/MI_DEBUG_FULL=ON: 32/32 passed.
- ci/check_internal_state.py: 30/30 sites classified.
- ci/check_isa_baseline.py: clean.

memory-gate (ci/memory_gate.py, matching .github/workflows/
c-unit.yml's memory-gate job, 4 runs, min-of-4):
    peak_rss   58.2 MB   baseline 22.3 MB   allowed 25.6 MB (+15%)
    FAIL: peak_rss regressed +161.0% (min run 58.2 MB vs 22.3 MB)

Isolated whether this function is the cause: rebuilt with the
call site reverted to the disabled/no-call state (everything else at
this commit's HEAD unchanged) and re-ran the same 4-run gate --
**peak_rss stayed at 58.2 MB, unchanged**. So this specific change is
NOT the source of the regression; it is present throughout the pin
bump (some combination of the 205 upstream commits -- e.g. the
2-level page map, pre-allocated initial tld/theap, or page field
reordering -- moved the baseline). Per instruction, NOT re-baselining
and NOT silently re-disabling the collector to paper over a red gate
that isn't attributable to this change: reporting the FAIL as-is for
the coordinator to decide (re-baseline deliberately with rationale, or
bisect the 205-commit range further).

Committed baselines (ci/memory-baselines/*.json) are left untouched.

Refs #266, #128

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YT4jVokb2gdT8ngFrH8i8S

mi_theap_realloc_zero_ex's memevt-resize tail re-derived the new
block's page via _mi_ptr_page(newp), but newpage (the ppage out-param
from the _mi_theap_malloc_zero call just above) is already in scope
and is the same page. Use it directly.

Refs #266

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YT4jVokb2gdT8ngFrH8i8S

src/page.c and src/prim/windows/prim.c changed in the review-response
fixes (restoring upstream's MinGW detection and re-enabled
mi_theap_collect_full_pages). Regenerate rust/mimalloc-pprof/vendor/*
via `cargo run -p xtask -- amalgamate-c` and `amalgamate-h`.
`cargo run -p xtask -- check` confirms the vendored copy matches
src/include; `cargo build --workspace` and `cargo test -p
mimalloc-pprof` both pass.

Refs #266

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YT4jVokb2gdT8ngFrH8i8S

`ruff format --check ci/` fails on this file (pre-existing on main,
per the c-unit baseline). Run `ruff format ci/check_crate_package.py`
to match CI's `.github/workflows/python-lint.yml` step exactly;
`ruff check ci/` and `ruff format --check ci/` both pass afterward.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YT4jVokb2gdT8ngFrH8i8S

CI's memory-gate runners are 4-core; this test's peak RSS/commit scales
with how many concurrently-running churn threads the OS actually
schedules onto distinct CPUs, not just with the allocator's true
high-water mark. Measured on this repo: 58 MB on an unrestricted
16-core host vs ~23 MB under `taskset -c 0-3` on the same host, same
binary and commit -- an apples-to-oranges comparison against the
4-core baselines with nothing in the JSON schema to flag it as such.
This was the actual cause of the local "regression" investigated in
an earlier commit on this branch (see d6aee24's body): re-verified
after that CPU-affinity confound was understood, the local number
matches CI (~23-25 MB) once pinned, so the earlier apparent +161%
regression was a measurement artifact, not a real one.

`ci/memory_gate.py check` (no path arguments) now locates the most
recently built `mimalloc-test-memory-gate` binary under build*/ or
out/*/, runs it RUNS_EXPECTED times pinned to <= 4 CPUs via
os.sched_setaffinity (Linux only; no-ops elsewhere, matching where CI
itself does not pin), and checks the results -- reproducing the CI job
locally in one command. Explicit-path invocations (`check
<result.json>...`, `update`, `control`) are unchanged.

Verified locally: `python ci/memory_gate.py check` now reports ~23 MB
and PASSes against the committed ubuntu baseline (22.3 MB, +15%
allowed). No ci/tests/ coverage exists for this script.

Also records (docstring only, no threshold/baseline change): main's
docs-only PR #275 failed ubuntu's memory-gate at +15.7%, just over the
15% tolerance, with no allocator-path changes at all -- evidence the
tolerance is closer to the noise floor than assumed. Deliberately not
addressed here; needs its own measurement-backed PR.

Refs #266

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YT4jVokb2gdT8ngFrH8i8S

The selftest's positive control located the per-thread-tls-slot-array
site by matching a hardcoded old-pin call shape
(mi_heap_rezalloc(mi_heap_main(),...)), which no longer exists after
#266's pin bump -- that site now normally allocates via
_mi_meta_rezalloc, with mi_heap_rezalloc(_mi_theap_heap(...),...)
surviving only as the MI_TEST_TLS_CONTROL negative-control path.
`next(...)` found no match and raised StopIteration, failing
diagnostic-gates CI unconditionally (`check_internal_state.py --selftest`
runs after the real check, which itself already passes).

Retarget the selftest at that surviving site by its current call
shape. `python3 ci/check_internal_state.py --selftest` now passes.

Refs #266

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YT4jVokb2gdT8ngFrH8i8S

ctest-debug-full-win-gnu (C) and rust-native's test-win-gnu
(bench-harness's planted_control, Rust) both fail identically:

  mimalloc: assertion failed: ... options.c:448, mi_add_stderr_output
    assertion: "mi_out_default == NULL"

Same assertion, same file, in two unrelated consumers that only share
the win-gnu target -- strong evidence this is a real double-invocation
of process init on that platform, not a test-specific issue.

`_mi_options_post_init()` (init.c) is called unconditionally from
`_mi_auto_process_init`, "called once by the process loader ... before
main is called" per its own comment -- but unlike `mi_process_init`
(which IS do-once guarded via mi_atomic_do_once), that call is not
itself guarded against running twice; it is only as single-invocation-
safe as whatever constructor mechanism actually calls
`_mi_auto_process_init`. `mi_add_stderr_output`/its caller are
byte-identical between bcee5a88 and 6def7be9, so this isn't a
regression in that function -- the likely trigger is upstream
`1cf88691` (in the bcee5a88..6def7be9 range), which switches MinGW
from MI_WIN_INIT_USE_FLS to the "default" win init path, changing
which constructor mechanism registers on win-gnu.

Not reproducible locally (no MinGW cross-compiler available in this
environment) to confirm which of the two constructor entry points
fires twice. Rather than chase that blind, make the assertion's
target idempotent instead: a second call is meant to be a harmless
re-affirmation that stderr output is now safe, not a distinct state
transition, so skip re-initializing if already done rather than
asserting. This is safe regardless of the exact double-invocation
mechanism and does not change single-invocation behavior (still
covered by every other passing test on every other platform).

Refs #266

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YT4jVokb2gdT8ngFrH8i8S

ctest-guarded's second pass (MIMALLOC_GUARDED_SAMPLE_RATE=1, forcing
every allocation through the guarded allocator) failed test-profile,
test-memory-events, and test-dhat. Root cause chain, found by
bisecting each failure forward:

1. `_mi_theap_malloc_guarded`'s inner over-allocated request (block +
   trailing guard page) reaches the same hooked block-construction
   path as any other allocation (mi_page_malloc_zero, via
   _mi_malloc_generic), so its memevt/profiler hooks fired with that
   inflated internal size instead of the caller's actual request --
   unlike alloc-aligned.c's mi_theap_malloc_guarded_aligned, which
   already suppresses and re-fires memevt correctly for the same
   underlying call. alloc.c's two direct dispatch sites
   (mi_theap_malloc_small_zero_nonnull, mi_theap_malloc_generic) had
   no such correction at all.

   Fixed by suppressing both memevt and the profiler (new
   _mi_prof_suppress_begin/end in profile.c, reusing the existing
   prof_callback_depth re-entrancy guard) around the guarded call, then
   firing one corrected event/sample with the real size afterward.

2. That correction initially recorded the profiler sample keyed by the
   caller-visible (interior, for a guarded block) pointer, but
   profile.c's free-side lookups (prof_free_record, called from
   free.c with the block start via _mi_page_ptr_unalign) and
   prof_realloc_in_place (called with the caller's raw, possibly
   interior pointer) disagree with each other about which identity to
   use -- a pre-existing inconsistency never exercised before this,
   since guarded + profiler sampling of the same allocation was never
   connected. Standardized on the block start everywhere: alloc.c's
   correction now records under _mi_page_ptr_unalign(page,ptr), and
   prof_realloc_in_place unaliases its `p` before matching (a no-op
   for the common non-guarded case, where a pointer already is the
   block start).

3. Freeing a guarded page's one-and-only block immediately retires and
   returns that page to the arena (src/page.c's _mi_page_free clears
   has_interior_pointers as part of that). test-memory-events'
   deliberate second mi_free (testing double-free detection) and all
   of test-dhat's exact-count assertions assume a freed block's page
   sticks around, an assumption forced guarding on every allocation
   breaks for any single-block-per-page guarded object. Both are about
   double-free detection / DHAT accounting precision, not about the
   guarded allocator itself, so both now disable guarding
   (mi_theap_guarded_set_sample_rate(..., 0, 0)) for the specific
   allocations/whole test run that need it, rather than chasing
   guarded-specific behavior neither was written to exercise.

4. test-profile.c's dump_text capture buffer (64 KiB) was sized for
   un-guarded runs; guarding every allocation gives every sampled
   allocation its own distinct guard page, producing more/larger dump
   entries. Bumped to 4 MiB.

Separately: internal allocator bookkeeping (tld/theap/subproc structs,
the TLS slot array) now allocates via the hooked path since #266's pin
bump (subproc.c's _mi_meta_zalloc/_mi_meta_rezalloc route through
mi_theap_zalloc(subproc->theap_meta, ...) rather than the old
arena-meta.c's direct arena allocation) -- and theap_meta inherits
MIMALLOC_GUARDED_SAMPLE_RATE like any other theap. Guarding internal
bookkeeping serves no purpose (there is no application buffer-overrun
to catch there) and was a contributing red herring while isolating the
above, so theap_meta now always has guarded_sample_rate=0, set right
after its two _mi_theap_init call sites (init.c's process-main
bootstrap, subproc.c's mi_subproc_new).

Verified: full ctest-guarded locally, both passes (normal + forced
guarding via MIMALLOC_GUARDED_SAMPLE_RATE=1), 25/25 each.

Refs #266

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YT4jVokb2gdT8ngFrH8i8S

src/alloc.c, src/init.c, src/options.c, src/profile.c, src/subproc.c,
src/page.c, src/prim/windows/prim.c, and include/mimalloc/internal.h
all changed in this round of review fixes (#266): restoring upstream's
MinGW detection, adopting upstream's re-enabled
mi_theap_collect_full_pages, correcting guarded-allocation hook
accounting, and making mi_add_stderr_output idempotent -- the last of
which is exactly what test-win-gnu (bench-harness's planted_control)
was hitting. Regenerate rust/mimalloc-pprof/vendor/* via `cargo run -p
xtask -- amalgamate-c` and `amalgamate-h`. `cargo run -p xtask --
check` confirms the vendored copy matches src/include; `cargo build
--workspace` and `cargo test -p mimalloc-pprof` both pass.

Refs #266

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YT4jVokb2gdT8ngFrH8i8S

…anchor test

- memory_gate.py: type the preexec hook explicitly instead of an untyped
  **kwargs dict (pyright strict: "Argument type is unknown").
- test_benchmark_report.py: the README's Performance section links the
  dashboard root since #257-#263, not #throughput/#history anchors; this
  assertion was already red on main but hidden behind the earlier
  ruff-format failure.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YT4jVokb2gdT8ngFrH8i8S

Corrects a misdiagnosis in fe76d06's commit message: that commit's
claim 3 attributed test-memory-events.c's and test-dhat.c's guarded-
mode failures entirely to page reclaim-on-free. That was wrong for
test-dhat.c. The actual bug, found and verified by review: alloc.c's
guarded-allocation correction (added in fe76d06) recorded the
memevt ALLOCATE event under `gp`, the INTERIOR (block+guard-offset)
pointer `_mi_theap_malloc_guarded` returns -- while every free-side
hook (free.c's mi_free_block_local/_mt call _mi_prof_on_free/
_mi_memevt_on_free with the BLOCK START, via
mi_validate_block_from_ptr/_mi_page_ptr_unalign) and DHAT (dhat.c,
keying by that same block-start pointer) look a live record up by a
DIFFERENT identity. Confirmed by measurement: 32 malloc+free pairs
under forced guarding left live_blocks=32 (every one leaked) before
this fix, 0 after. The two-lines-above profiler correction already
used _mi_page_ptr_unalign correctly -- only memevt's call was wrong.

Fix: `_mi_memevt_on_alloc` now takes the same _mi_page_ptr_unalign'd
block pointer as the profiler correction beside it, both at alloc.c's
two guarded dispatch sites and at alloc-aligned.c:53
(mi_theap_malloc_guarded_aligned), which has the identical bug --
pre-existing there since fe76d06 only fixed memevt's suppression,
not its pointer identity, and never touched the profiler for that
path at all (also added here).

Rule 6: alloc.c's two call sites were near-identical ~26-line blocks.
Collapsed into one static mi_theap_malloc_guarded_hooked helper inside
`#if MI_GUARDED`, so each upstream call site is one line again.

Re-examined both test exemptions this bug motivated, per review:
- test-dhat.c's `mi_theap_guarded_set_sample_rate(...,0,0)` exemption:
  REMOVED. Verified the file now passes forced guarding (3/3 runs)
  without it -- it was masking exactly this pointer bug.
- test-memory-events.c's T6 double-free exemption: KEPT, re-verified
  independently still needed (reverting it alone still faults in
  mi_validate_block_from_ptr the same way as before -- guarded-page
  reclaim-on-free, unrelated to the pointer bug just fixed). Attempted
  restoring the sample rate afterwards, as review asked; that surfaced
  two more pre-existing, unrelated gaps further down this same file
  (test_concurrency/T7: a deterministic loss of exactly T7_THREADS
  FREE events out of 16000 every run; test_visit_live_allocations/T11:
  a tracked-allocation assertion). Both are out of scope here -- guarding
  was never actually exercised past this point before, so neither is a
  consequence of the pointer bug. Left the rate un-restored and said so
  in the comment, rather than restoring into two new red tests this
  commit can't explain.

Verified: full guarded ctest-guarded-style suite (both passes) green,
24/24 normal-mode-equivalent + all long-running tests.

Refs #266

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YT4jVokb2gdT8ngFrH8i8S

Round 1 made mi_add_stderr_output idempotent as a defensive patch over
the symptom. Review correctly identified that as treating the symptom,
not the cause: the double-invocation is real, not hypothetical.

CI's win-gnu jobs use MINGW64/msvcrt, so MI_MINGW_UCRT64 is unset
(CMakeLists.txt). That leaves MI_PRIM_HAS_PROCESS_ATTACH undefined for
the plain `#elif defined(__MINGW32__)` TLS-callback path
(src/prim/windows/prim.c) upstream `1cf88691` switched MinGW onto
(replacing MI_WIN_INIT_USE_FLS, which DID define that macro -- so this
was unreachable at our previous pin). Without it,
src/prim/prim.c's MI_PRIM_HAS_PROCESS_ATTACH-gated code still falls
through to a GCC `__attribute__((constructor))` calling the same entry
point. So on win-gnu, `_mi_auto_process_init` runs twice: once via the
registered `mi_tls_attach` TLS callback's DLL_PROCESS_ATTACH, once via
the constructor. Its own comment says "Called once by the process
loader ... before main is called" -- that contract needs enforcing,
not working around one of its side effects.

Wrap the whole function body in `mi_atomic_do_once` (its own,
function-scoped do-once guard -- `mi_process_init()` inside already
has its own separate one for a narrower reason). A second call is now
a true no-op. Keeps mi_add_stderr_output's idempotency as
belt-and-suspenders.

Not reproducible locally (no MinGW cross-compiler in this
environment); reasoned from source plus corroborating evidence from
two independent consumers (C ctest-debug-full-win-gnu, rust-native's
win-gnu bench-harness test) hitting the identical assertion.

docs/upstreaming.md: records this as a pr/* candidate with the full
mechanism, alongside the existing (now-resolved) __MINGW32__ typo
entry it's adjacent to in the upstream history.

Refs #266

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YT4jVokb2gdT8ngFrH8i8S

…note

ctest-shared (windows-latest) is a real regression from the #266 pin
bump, not the known-red #69 diagnostic .github/workflows/c-unit.yml's
comments claimed: #69 (MIMALLOC_MEMORY_EVENTS env activation in an
MSVC DLL build) is resolved -- windows-latest was confirmed green on
main (runs 33565889274, 33546799862) well before this PR. The stale
comment claiming windows-latest was deliberately kept in this matrix
red for #69 is corrected; it was actively misleading (a real new
regression reads as "the expected old failure").

The regression itself: test-profile/-accum/-auto fail at
test/test-profile.c's cross-thread-free-of-sampled-blocks check
(after.live_samples == 0). Mechanism, worked out by reading the
6def7be9 free.c/arena.c abandon+reclaim paths (largely unchanged
structurally from bcee5a88, so not a code regression there, but the
race window it always had is real): a cross-thread mi_free on an
abandoned page pushes onto page->xthread_free and, only on the free
that transitions ownership, drains it and fires
_mi_prof_on_free_collect (src/free.c's mi_free_try_collect_mt via
mi_page_thread_collect_to_local, page.c). Frees landing after that
drain but before mi_abandoned_page_unown_from_free finishes releasing
ownership are caught by its own retry loop -- but frees landing AFTER
ownership is released are not swept by anything until some thread
specifically reclaims that exact page again, which mi_collect does
not guarantee (it only visits pages the calling theap currently owns,
not every abandoned page in the subproc). A profiler record can then
stay "live" indefinitely. This is a general property of the lock-free
abandon/reclaim design, not something introduced by the pin bump;
Windows apparently hits the timing window far more reliably than
Linux (200-round Linux stress of the exact scenario, added below,
never reproduces it).

Narrows (cannot fully close, for the reason above) the window: added
one _mi_page_free_collect sweep to the top of
_mi_arenas_page_abandon (src/arena.c), the single point all three
(re-)abandon call sites funnel through, so every (re-)abandon
reconciles any not-yet-collected xthread_free right before the page
becomes invisible to future theap-level collects.

test/test-profile.c: wrapped test_cross_thread_free_of_sampled in a
200-round stress loop per review's request for a Linux-reproducible
variant (worker frees then fully exits, matching xthread_run's
existing join/WaitForSingleObject, before main collects). Passes
locally, 200/200 rounds, confirming this either doesn't reproduce on
Linux or the arena.c narrowing is sufficient here; CI will confirm on
Windows.

Refs #266

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YT4jVokb2gdT8ngFrH8i8S

BLOCKING: ctest-debug-full (macos-latest) test-stress-dynamic aborted
with `reentrant_internal_lock_acquisition` at atomic.h:535
(mi_lock_acquire), green on main (job 100082543057). Failed almost
immediately (0.05s, right at DYLD_INSERT_LIBRARIES-driven early
process bootstrap with 8 threads starting), consistent with a
first-touch race rather than deep into the stress workload.

This is a real, upstream-inherited hazard, not a diagnostic false
positive -- confirmed by upstream's own comment in _mi_meta_rezalloc
(subproc.c, "since we take a meta lock we cannot use mi_theap_rezalloc
as that could call mi_free which can call mi_stat_free which would try
to take the meta lock again. See issue #1358"), which already works
around one instance of exactly this class of bug. The other two
functions, _mi_meta_zalloc and _mi_meta_zalloc_aligned, were not
covered: their `mi_theap_zalloc(subproc->theap_meta, size)` call can,
if theap_meta needs a fresh arena page, need arena bookkeeping
allocated from `heap_main` (src/arena.c's mi_heap_zalloc_aligned call
on arena->subproc->heap_main), which -- on a thread that has never
touched heap_main before -- bootstraps that thread's heap_main theap
(src/theap.c ~317), which calls _mi_meta_zalloc again for the SAME
subproc, reaching this file recursively on the same thread while
subproc->theap_meta_lock (a plain, non-recursive pthread_mutex on
macOS) is still held by the outer call. On a real (non-debug) build
this would deadlock, not just trip the checker.

Fix: track, per thread, which subproc's meta lock is currently held
(mi_meta_lock_thread_owner, thread-local). A nested call targeting the
SAME subproc skips re-acquiring -- the outer lock already protects
it, giving recursive-mutex semantics without changing mi_lock_t's type
(which backs every other lock in the codebase). A nested call for a
genuinely different subproc is unaffected and still locks normally.

Not reproducible locally under MI_DEBUG_FULL + MI_BUILD_SHARED (no
macOS available here); reasoned from source and upstream's own
corroborating comment. Verified the fix doesn't regress anything:
full ctest, both plain and MIMALLOC_GUARDED_SAMPLE_RATE=1, and
Debug/MI_DEBUG_FULL/MI_BUILD_SHARED test-stress-dynamic specifically,
all green on Linux.

docs/fork-divergence.md: adds the theap_meta guarding-exemption row
(#266 round 1) the LOW review item asked for, and points to it from
the two call sites (src/init.c, src/subproc.c).

Refs #266

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YT4jVokb2gdT8ngFrH8i8S

src/alloc.c, src/alloc-aligned.c, src/arena.c, src/init.c, and
src/subproc.c all changed in this round's review fixes (#266): the
guarded-allocation DHAT pointer-identity fix, the real MinGW
double-process-init fix (mi_atomic_do_once), the cross-thread
sampled-free reclamation narrowing, and the theap_meta_lock
reentrancy fix. Regenerate rust/mimalloc-pprof/vendor/* via `cargo
run -p xtask -- amalgamate-c` and `amalgamate-h`. `cargo run -p xtask
-- check` confirms the vendored copy matches src/include; `cargo
build --workspace` and `cargo test -p mimalloc-pprof` both pass.

Refs #266

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YT4jVokb2gdT8ngFrH8i8S

…isition"

This reverts commit 8e878f1.

The cited same-thread re-entry path does not exist. The meta theap
belongs to heap_main, so mi_heap_ensure_arena_pages (src/arena.c:688-690)
takes the _mi_is_heap_main branch and never allocates -- it assigns
arena_pages = &arena->pages_main directly, with no call into
mi_arena_pages_alloc or any other allocation path. There are also no
_mi_meta_* calls anywhere in arena.c, page-map.c, or bitmap.c (confirmed
by grep) that could re-enter _mi_meta_zalloc/_mi_meta_zalloc_aligned on
the same thread while subproc->theap_meta_lock is held.

The change also did not fix the macOS ctest-debug-full failure it was
meant to address: with this commit applied, the failure mutated from
reentrant_internal_lock_acquisition at atomic.h:535 into 8x
mi_page_is_valid_init assertions at src/page.c:91 followed by SIGTRAP
(job 100089540093), indicating the thread-local recursive-mutex
emulation papered over the symptom without touching the actual cause.

Refs #266

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YT4jVokb2gdT8ngFrH8i8S

…est loop)

Partially reverts commit 5e591a9: drops the
_mi_page_free_collect() sweep added to the top of _mi_arenas_page_abandon
(src/arena.c) and the 200-round stress loop wrapped around
test_cross_thread_free_of_sampled (test/test-profile.c). The
.github/workflows/c-unit.yml #69 comment correction from that commit is
KEPT -- it is a genuine, independently-correct fix (windows-latest was
confirmed green on main well before this PR) and unrelated to the C
mechanism being reverted here.

Reason: the added collect is redundant and, on one caller, actively wrong.
_mi_page_abandon (src/page.c:299-300) already calls _mi_page_free_collect
and checks mi_page_all_free before ever reaching _mi_arenas_page_abandon,
so the sweep added at the top of _mi_arenas_page_abandon itself duplicates
that work for that call path. For the other caller,
_mi_arenas_page_try_reabandon_to_mapped, the collect ran AFTER that
function's own mi_assert_internal(!mi_page_all_free(page)) (src/arena.c:1187,
Debug-only), meaning a page draining to all-free during the sweep would
still be abandoned via the arena path instead of freed the way upstream's
_mi_page_abandon would -- likely the actual cause of the memory-gate
regression seen on this branch (26.5 MB vs the ~22.3 MB baseline) and of
the rust benchmark-suite::timed_allocation_audit failures on Windows in
run 33579151945, not a fix for the cross-thread reclamation gap it was
meant to narrow.

Also, the MSVC ctest-shared failure this commit targeted is deterministic,
not the racy window the commit's analysis assumed: round 0/200 fails with
identical live_samples=2 live_bytes=8200 across all three affected test
binaries (test-profile, test-profile-accum, test-profile-auto). A fixed
round-0 failure with an identical byte count every run is not consistent
with a lock-free timing race; see the follow-up commit on this branch
diagnosing and fixing the real, deterministic cause (allocator-internal
meta-page allocations getting sampled).

Refs #266

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YT4jVokb2gdT8ngFrH8i8S

MSVC ctest-shared's test-profile/-accum/-auto failures at
test_cross_thread_free_of_sampled were deterministic, not the
lock-free timing race the now-reverted arena.c change assumed: round
0/200 failed with identical live_samples=2 live_bytes=8200 across all
three affected test binaries. An identical byte count on the very
first round is not consistent with a race.

Root cause: mi_tld_t and mi_theap_t are allocated via _mi_meta_zalloc
onto a dedicated, detached theap (subproc->theap_meta) whenever a
fresh OS thread first touches mimalloc (src/init.c's mi_tld_create,
src/theap.c's _mi_theap_alloc). Both go through the normal
mi_theap_zalloc allocation path, so they hit the same profiler hooks
as any user allocation, and both are large relative to typical sample
rates (sizeof(mi_theap_t) is several KB), so they get sampled almost
every time a new thread is created. Confirmed on Linux: a small
harness that starts profiling at an aggressive rate, spawns worker
threads that each do one 256-byte malloc/free and join, then calls
mi_collect(true), shows a 144-byte sample (sizeof(mi_tld_t)) and an
~8104-byte sample (sizeof(mi_theap_t) minus padding) still live after
every worker thread has exited and been joined -- these numbers are in
the same neighborhood as the MSVC failure's live_bytes=8200 for
live_samples=2. On an MSVC DLL build these metadata blocks are freed
from DLL_THREAD_DETACH, which can run after the owning thread's own
tld has already been torn down, on a path mi_collect(true) never
revisits, so the sample stays "live" forever there deterministically
rather than racily.

Fix: _mi_prof_on_alloc (src/profile.c) now early-returns for a page
identified by the existing _mi_meta_is_meta_page(subproc, page) helper
(src/subproc.c, already declared in internal.h) via the new
mi_page_subproc(page) inline helper (internal.h) -- cheap, no extra
TLS load, since the page's owning heap already carries its subproc.
page->has_metadata is consequently never set for a meta page, so
_mi_prof_on_free/_mi_prof_on_free_collect need no matching change:
there is nothing on the page for them to find.

The same exclusion is applied to memory-events (src/memory-events.c),
symmetrically on both _mi_memevt_on_alloc and _mi_memevt_on_free --
memevt_live_bytes/memevt_live_count are running deltas, so excluding
only one side would under/overflow them. This is also DHAT's only
entry point (_mi_dhat_begin_alloc/_mi_dhat_begin_free are called
exclusively from these two functions), so the same check excludes DHAT
too; DHAT's free side needs no separate check since it looks up the
pointer in its own record table and no-ops when the alloc was never
recorded. This also resolves the "inherited semantic change" flagged
on #266 (internal metadata previously counted as a user allocation)
and removes the theap_meta_lock callback hazard that the reverted
recursive-mutex commit was trying to work around from the other
direction.

test/test-profile.c: added test_meta_pages_never_sampled, which spawns
64 fresh threads that each allocate and free one 256-byte block, then
asserts both live_samples==0 and (via mi_prof_visit) that no live
sample's average size is >= 4000 bytes -- the latter is the targeted
regression check, since it would catch a meta-page sample even if
live_samples were nonzero for an unrelated reason. Verified this test
fails (assertion on live_samples==0) without the src/profile.c and
src/memory-events.c changes above, and passes with them; full ctest
(25/25) passes on Linux Release with MI_PPROF=ON.

Refs #266

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YT4jVokb2gdT8ngFrH8i8S

macOS ctest-debug-full's test-stress-dynamic hit
reentrant_internal_lock_acquisition at atomic.h:535 (run 33573550217).
The now-reverted thread-local recursive-mutex commit tried to fix this
by assuming a real same-thread re-entry path into theap_meta_lock, but
that path does not exist (see the revert commit), and applying it did
not fix the macOS failure -- it mutated into 8x mi_page_is_valid_init
assertions at page.c:91 then SIGTRAP (run 33579151945), consistent
with papering over the symptom rather than the cause.

Leading hypothesis instead: the #266 pin bump rewrote prim-tls.h and
added prim/prim-tls.c; macOS uses MI_TLS_MODEL_PTHREADS, and a
degenerate or colliding thread id during dylib bootstrap (this fork's
lock diagnostics run via DYLD_INSERT_LIBRARIES-driven early process
init) would look exactly like a reentrant acquisition to the current
checker, which only compares tagged thread ids without ever printing
them.

mi_lock_debug_fail (src/diagnostic.c) now takes the current thread's
and the lock's recorded owner's mi_lock_debug_thread()-tagged ids and
includes them in the failure message (current_tid=... owner_tid=...),
for all four lock-diagnostic failure kinds (reentrant acquisition,
owner not cleared, release by non-owner, destroy while owned); the two
non-lock diagnostics (_mi_diagnostic_check_tls_owner,
_mi_diagnostic_check_zero) pass 0/0, unchanged in behavior. This tells
the next macOS run whether the reentrant-acquisition failure has
current_tid == owner_tid because of genuine same-thread reentrancy, or
because both come out to the same degenerate/zero value during
bootstrap -- confirming or ruling out the prim-tls hypothesis.

Verified locally: full Debug + MI_DEBUG_FULL + MI_BUILD_SHARED ctest
(32/32, including test-lock-reentrancy/-uncleared-owner/-nonowner-
release/-destroy-owned, which substring-match on the unchanged reason
string so are unaffected by the added fields) passes on Linux; ran
mimalloc-test-lock-reentrancy reentrant directly to confirm the new
fields render, e.g.:
  reentrant_internal_lock_acquisition lock=... current_tid=130633077629313
  owner_tid=130633077629313 at .../atomic.h:535 (mi_lock_acquire)

Refs #266

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YT4jVokb2gdT8ngFrH8i8S

Run 33581454510 (ctest-debug-full macos-latest, PR #276) confirmed with
the previous diagnostic that the reentrant_internal_lock_acquisition at
atomic.h:535 is a genuine same-thread reentrancy: current_tid==owner_tid,
both large non-degenerate values, not a bootstrap thread-id collision.
That rules out the earlier hypothesis but doesn't say which lock or which
nested call path re-enters it.

mi_lock_debug_fail (src/diagnostic.c) now, after the existing message:
- Identifies the lock by address against the three mi_subproc_t locks
  reachable without adding any new declarations to upstream headers
  (mi_subproc_t is already a complete type here via internal.h/types.h,
  and _mi_subproc_main is already declared in internal.h):
  theap_meta_lock, heaps_lock, arena_reserve_lock. mi_thread_locals_lock
  (threadlocal.c) is `static` to that TU and not reachable from here, so
  it is intentionally left unnamed -- the backtrace below still covers it.
- Prints a native backtrace via backtrace()/backtrace_symbols_fd() on
  __APPLE__ or __GLIBC__, guarded behind MI_DEBUG > 2 like the rest of
  this file. backtrace_symbols_fd (unlike backtrace_symbols) never calls
  malloc -- it writes directly to the fd -- consistent with this file's
  own never-allocate constraint on its failure paths.

No change needed to .github/workflows/c-unit.yml: ctest-debug-full
already runs with --output-on-failure, so the new lines will show.

Verified locally on Linux: Debug + MI_DEBUG_FULL rebuilds clean,
`ctest -R lock` (test-lock-reentrancy/-uncleared-owner/-nonowner-release/
-destroy-owned) all pass -- confirmed manually running
mimalloc-test-lock-reentrancy reentrant that both a backtrace and the
existing current_tid/owner_tid fields print correctly (lock-name line is
correctly absent here since the test's own dummy lock is none of the
three named subproc locks). Release ctest (25/25) also passes unaffected
(diagnostic.c is not compiled in when MI_DEBUG<=2).

Refs #266

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YT4jVokb2gdT8ngFrH8i8S

src/diagnostic.c changed (9d8ca04: backtrace + lock identification on
reentrancy failure). Regenerate rust/mimalloc-pprof/vendor/* via `cargo
run -p xtask -- amalgamate-c` and `amalgamate-h`. `cargo run -p xtask --
check` confirms the vendored copy matches src/include; `cargo build
--workspace` passes.

Refs #266

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YT4jVokb2gdT8ngFrH8i8S

…tu-latest)

min-of-4 on ubuntu-latest was flaky enough to flip PASS/FAIL between
consecutive pushes of the *same* Release object code on PR #276 --
diagnostic.c-only commits do not touch the Release build, so these are
byte-identical binaries:

  238218d -> 24.7 MB PASS (spread 17.8%)
  5d1d6ae -> 26.5 MB FAIL (spread  9.1%)
  32e0856 -> 25.4 MB PASS (spread 23.2%)
  0e23010 -> 29.2 MB FAIL (spread 14.7%)   <- identical Release code to 32e0856

main's docs-only PR #275 (no allocator-path changes at all) also failed
at 25.8 MB (+15.7%). Four of these five spreads are at or above
PEAK_TOLERANCE (15%) itself -- ci/memory_gate.py's own comment already
said "raise RUNS_EXPECTED or the tolerance, with this measurement as
the justification"; these five measurements are that justification.

ci/memory_gate.py: RUNS_EXPECTED 4 -> 8, with a dated comment quoting
the five measurements above in place of the old "known margin, not yet
acted on" paragraph. PEAK_TOLERANCE stays 0.15.
ci/memory-baselines/*.json is untouched: the committed baselines are
min-of-4 (22.3 MB linux, #70), and a min-of-8 of the same underlying
peak-RSS distribution can only be <= a min-of-4 of that distribution,
never higher -- so this change is strictly conservative against those
baselines, it can only remove noise-driven false failures, not
manufacture a false pass.

.github/workflows/c-unit.yml: both memory-gate loops (the real
measurement and the leak positive control, which shares the same
report_runs() path and its RUNS_EXPECTED-driven run-count warning) now
emit 8 runs instead of 4, with comments updated accordingly.

No change needed to memory_gate.py's baseline-vs-supplied-run-count
logic: `baseline_runs` in the committed JSON is write-only (set by
`update`, never read by `check`), so a baseline recorded as min-of-4
being compared against 8 freshly-supplied runs neither warns nor fails.

Verified: `ruff check ci/` and `ruff format --check ci/` clean;
`python3 ci/memory_gate.py 2>&1 | grep -q "Exit codes"` matches;
`uvx --with pyyaml==6.0.2 --with pytest==8.3.4 python -m pytest ci/tests -q`
72/72 pass; manually ran `memory_gate.py check` against 8 locally
generated result files (no baseline-count warning, spread dropped to
0.3% with min-of-8 vs single-digit-percent spreads with fewer runs).

Refs #266

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YT4jVokb2gdT8ngFrH8i8S

Replace every ci/tests/*.py sys.path.insert(0, ...) anti-pattern with
pytest's built-in `pythonpath = ["ci"]` config in pyproject.toml, so tests
keep their existing flat `import <module>` lines without hand-rolling
sys.path.

Also stop invoking Python as a bare `python3`/`python` anywhere docs or
ci/verify_local.py shell out to it: docs/dev-loop.md, CLAUDE.md's "Fast
local iteration" line, and every subprocess verify_local.py spawns now go
through `uv run` (pinned to the same ruff/pyright/pyyaml/pytest versions
.github/workflows/python-lint.yml installs), with the `diag` and `lint`
configs SKIPPED (not failed) with a clear reason when `uv` isn't on PATH,
matching the existing clang-missing SKIP pattern for `asan`.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YT4jVokb2gdT8ngFrH8i8S

… TLS

macOS CI backtrace (run 33582191949 job 100098610697, ctest-debug-full
(macos-latest), test-stress-dynamic), abbreviated:

  2  _mi_meta_zalloc            <- re-entry (second acquire)
  6  libsystem_malloc _malloc_type_calloc_outlined  <- dyld calloc, interposed
  7  libdyld ThreadLocalVariables::instantiateVariable
  8  libdyld _tlv_get_addr      <- lazy instantiation of a __thread variable
  9  _mi_memevt_on_alloc + 40   <- our hook touches a mi_decl_thread variable
 12  _mi_meta_zalloc            <- first acquire (worker thread's own tld/theap)
 16  test-stress-dynamic stress()  (worker thread's first malloc)

Mechanism: a worker thread's first-ever malloc allocates its own tld/theap via
_mi_meta_zalloc, which holds subproc->theap_meta_lock for the duration. That
allocation itself fires _mi_memevt_on_alloc, which used to be the very first
thing to touch memevt_suppress_depth -- a file-local `mi_decl_thread`
(`__thread`) int. On a macOS dylib, first-touching a `__thread` variable can
lazily allocate its TLS block via a dyld-interposed calloc, which reenters
mimalloc and tries to re-acquire theap_meta_lock on the same thread: a
same-thread deadlock on a non-recursive mutex (an assertion under
MI_DEBUG_FULL instead). Debug-only in CI because -O0 materializes the access;
Release hides it behind the enabled-check, but a macOS dylib user who enables
memory-events/profiler/DHAT would deadlock identically. profile.c and dhat.c
had the identical latent bug via the same code path (dhat.c's begin_alloc is
reached only through _mi_memevt_on_alloc; profile.c's _mi_prof_on_alloc is
wired into the same allocation hot path).

Fix: move memevt_suppress_depth (memory-events.c), dhat_observer_depth /
dhat_event (dhat.c), and prof_callback_depth / prof_lock_owner (profile.c)
off `mi_decl_thread` and onto a new `mi_hooks_tld_t hooks` field on
`mi_tld_t` (include/mimalloc/types.h). A new fork-internal header,
include/mimalloc/hooks-tld.h, provides two peek-only accessors:

  _mi_hooks_tld_peek()          -- NULL if this thread has no tld yet (or no
                                    longer has one); never allocates, never
                                    touches a __thread variable.
  _mi_hooks_tld_peek_or_local() -- like peek, but falls back to a caller-
                                    owned stack `mi_hooks_tld_t` instead of
                                    NULL, for call sites that need real
                                    scratch state for the duration of one call.

Hook call sites split by reachability, not by "hot path vs. top-level":

- Alloc-side hooks (_mi_memevt_on_alloc, _mi_prof_on_alloc,
  _mi_dhat_begin_alloc) and mi_prof_start/mi_prof_start_ex (reachable via
  prof_auto_start() from _mi_prof_on_alloc) ARE reachable from inside
  _mi_meta_zalloc's locked region, so they peek and bail immediately on NULL
  -- always correct, since anything reaching them mid-init is by construction
  a meta allocation (the existing _mi_meta_is_meta_page check already
  excludes those from user-visible accounting).

- Free/resize-side hooks (_mi_memevt_on_free/_on_realloc_in_place/_on_resize)
  are never reachable from _mi_meta_zalloc (meta allocations only ever
  allocate), so a NULL peek there means something else: a thread with no tld
  of its own is legitimately freeing/resizing (e.g. a foreign thread's very
  first mimalloc call being a cross-thread mi_free -- see
  test_free_from_foreign_thread). These use peek_or_local instead of
  dropping the event.

- There is deliberately no "peek, or force init" accessor. An early attempt
  at one (mi_theap_get_default() when peek returned NULL) passed the full
  suite locally right up until test-api/test-stress/test-degenerate started
  failing an assertion in mi_thread_theaps_done: forcing thread init from a
  free hook is just as unsafe as from an alloc hook, but for a different
  reason -- mi_thread_theaps_done resets the default theap to the empty
  sentinel *before* freeing this thread's own theaps, specifically so
  nothing re-initializes it in that window (see its comment in init.c), and
  a free arriving after a thread's own mimalloc teardown already ran is an
  explicitly supported case (see free.c's "free'd after thread_done"
  comment). Do not add a forcing accessor back; hooks-tld.h documents this.

Two deliberate behavior changes from the old __thread-based design, both
scoped to a thread that has no tld of its own (never initialized one, or
already tore it down):

- DHAT no longer records a free/resize/finish from such a thread (dhat.c's
  begin_free/begin_resize peek and bail, not peek_or_local): dhat_prepare's
  armed event has to survive from begin_* until the *separate*
  _mi_dhat_finish_event() call, and a stack-local fallback cannot do that
  (its storage is gone the moment the begin_* function returns). memevt's
  always-on counters are unaffected (see _mi_memevt_on_free).

- mi_prof_visit is the one function in profile.c that still forces thread
  init (mi_theap_get_default(), inline, not exposed as a general helper):
  it holds prof_lock across a user callback, so a nested mi_free on the same
  thread must see prof_lock_owner==true through a *real*, shared
  mi_tld_t::hooks or it would try to re-acquire prof_lock and deadlock.
  This is safe (unlike the hot alloc/free hooks) because mi_prof_visit is a
  deliberate, top-level, user-initiated call, never reachable from
  _mi_meta_zalloc's locked region or from mimalloc's own thread-teardown
  machinery.

Also: types.h's mi_tld_detached static initializer needed an explicit
`{ 0 }` for the new hooks field (positional aggregate init) to keep
-Wmissing-field-initializers quiet.

Test: test/test-memory-events.c gains
test_new_thread_first_alloc_all_observers_active, spawning a thread whose
very first mimalloc call is a plain mi_malloc/mi_free with memory-events,
the profiler, and DHAT all active -- the exact CI shape, coverage-only on
Linux (the macOS-specific dyld trigger cannot reproduce there). Verified
locally: ctest-debug-full (MI_PPROF=ON, MI_DEBUG_FULL=ON), MI_PPROF=OFF
release, MI_GUARDED debug, clang+MI_TRACK_ASAN debug-full (all ctest, 100%
pass each), plus MI_BUILD_SHARED=ON debug-full test-stress-dynamic
standalone. python3 ci/check_internal_state.py and --selftest both pass
unchanged (30 sites; the internal-state inventory tracks allocation-site
provenance, not mi_decl_thread declarations). Full repo grep for
mi_decl_thread/__thread/_Thread_local confirms the only remaining hits are
internal.h's macro definitions and prim-tls.c/threadlocal.c/options.c's
pre-existing upstream-guarded uses (options.c's `recurse` var is upstream's
own _mi_preloading()-gated mitigation for this same class of bug;
prim-tls.c's __mi_theap_default/__mi_theap_cached are #if MI_TLS_MODEL_LOCAL
only, never compiled under macOS's MI_TLS_MODEL_PTHREADS; threadlocal.c's
mi_define_thread_local macro explicitly routes __APPLE__ to its pthread-key
branch) -- none reachable on macOS's PTHREADS model.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YT4jVokb2gdT8ngFrH8i8S

cargo run -p xtask -- amalgamate-c, following the C-core fix in the
previous commit (fix(hooks): keep per-thread hook state on mi_tld_t,
never in __thread TLS). mimalloc.h and mimalloc-stats.h are unchanged
(mi_hooks_tld_t is fork-internal, not part of the public surface those
vendor).

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YT4jVokb2gdT8ngFrH8i8S

The artifact step ran only on success, so a failing gate -- the one case
where the per-run numbers are needed to attribute growth or to re-baseline
deliberately -- produced no data. main's own run 33565889274 (docs-only PR
#275) failed the ubuntu gate at 25.8 MB (+15.7%) and uploaded nothing.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YT4jVokb2gdT8ngFrH8i8S

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YT4jVokb2gdT8ngFrH8i8S