I'm filing this here to see whether anyone else can reproduce, and to attach a Feedback for it: FB23457397.
Symptom. On macOS 15.7.7 (24G720), Mac16,8, 48 GB RAM, the system daemon launchservicesd grows its memory footprint monotonically across a boot — roughly 2 GB at ~9 days uptime, and ~4 GB at ~20 days on an earlier boot, at which point it crashes. Because Finder, Dock and cmd+tab hold XPC connections to it, the crash hangs the whole GUI shell (looks exactly like "Finder/Dock froze"). Memory only resets on reboot.
This is not a malloc leak: • "sudo leaks <pid>" = 0 leaks / 0 bytes — every region is reachable. • "sudo vmmap -summary <pid>" at ~2.0 GB footprint = VM_ALLOCATE ~2.0 GB across ~32,500 regions, plus a matching ~32,500 shared-memory regions, while the malloc heap is only ~100 MB. The daemon accumulates ~3–4 mach-memory-entry / shared-memory handles per minute and never releases them.
Note RSS is misleading here — macOS compresses the accumulated regions, so you must look at footprint (RSS + compressed), not RSS.
What drives it. The unified log ("log show --predicate 'process == "launchservicesd"' --info --debug") shows the daemon looping in tight retries:
launchservicesd: [com.apple.launchservices:cas] CopyProcessByPid(<pid>,NO) failed because session <N> didn't match expected <M>
The "expected" value increments on every retry. In one sampled hour: ~55,000 of these, with several "runaway minutes" of ~18,000 errors each (background is ~6/min). Each failed retry allocates an NSArray — which is exactly the __NSArrayI_new frame in the crash backtrace (EXC_BAD_ACCESS / SIGBUS in _xzm_segment_group_find_and_allocate_chunk). The burst trigger is a different short-lived XPC agent each time, dying at the moment of the session mismatch — so there is no single misbehaving client; it is the daemon's handling of the mismatch that spins.
The same "CopyProcessByPid ... didn't match expected" LaunchServices/CAS error has been observable since Ventura (13.x), where it surfaced as "file can't be found" on double-click; on 15.7.x it instead manifests as this unbounded region accumulation.
Can you reproduce? One command tells you if you have the same defect (not just generic "high memory"):
log show --predicate 'process == "launchservicesd"' --info --debug --last 1h | grep -c "didn't match expected"
Background is a few per minute. If you see tens of thousands, that is this bug. Check the daemon's footprint with "footprint <pid>" or Activity Monitor (Real Memory + Compressed), not RSS.
If it reproduces for you, please file your own Feedback and reference FB23457397 — duplicates are what get this prioritized. A sysdiagnose plus the JetsamEvent/crash .ips reports are available on request.
Has anyone seen whether this is addressed in macOS 26 or the macOS 27 betas?
