I’m seeing similar symptoms on macOS 15.7.9 (24G830) with fseventsd 1400.100.1, so this may also affect an older macOS release. Details here FB25224901 Before restarting the service, diagnostics showed: • Approximately 2.9 GiB physical footprint. • 5,212,296 live PathStringZone allocations, occupying approximately 1.6 GiB, with only about 1% fragmentation. • Approximately 2.8 GiB of writable memory marked swapped out. • The active notification-thread samples predominantly reached strncmp through the interned-string lookup chain. • A short filesystem trace recorded approximately 395 MiB of page-in requests over 5.4 seconds, almost entirely on the notification thread and backed by swap. These are summed request sizes, not unique pages or a sustained-rate measurement. Approximately six minutes after restarting only fseventsd, its footprint was 4,577 KiB, with 1,721 PathStringZone allocations. A separate short comparison trace recorded no page-in requests. Read-only inspection of this installed version also found the mechanism described here: a 32-bit cleanup cursor at event-table offset 0x14, advancing by 512 per complete pass, with cleanup skipped above 0xfffffdff. Starting from zero, that reaches 0xfffffe00 after 8,388,607 complete passes. Startup and successful table resizing reset the cursor; the inspected resize limit is 262,144 buckets. Important qualification: I did not capture the affected process’s live cursor value or zero-reference record counts before restarting it. This is therefore corroborating evidence for the hypothesis, not confirmation that cursor exhaustion caused my incident. The client mix also changed after restart, so this was not a controlled fixed-client comparison. No debugger attachment, process-memory modification, binary patching or SIP changes were used. I have prepared a privacy-minimized diagnostic summary containing the relevant aggregate measurements and code findings. Is there any additional narrowly scoped diagnostic that would help establish whether this older version is hitting the same failure mode?