René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"fs: `fs.watch` on MacOS leaks native memory each time a directory watcher is closed and reopened","articleBody":"### Version\n\nv26.0.0 (also v24.22.1)\n\n### Platform\n\n```text\nDarwin [Redacted] 25.6.0 Darwin Kernel Version 25.6.0: Tue Aug 18 17:51:47 PDT 2026; root:xnu-12377.161.15.700.19~2/RELEASE_ARM64_T6050 arm64\n```\n\n### Subsystem\n\nfs\n\n### What steps will reproduce the bug?\n\nOn MacOS, run this script using node. It closes and reopens N directory watchers and prints the mem growth as reported by `vmap`:\n```js\n    import { watch, mkdtempSync, mkdirSync } from 'node:fs';\n    import { tmpdir } from 'node:os';\n    import { join } from 'node:path';\n    import { execFileSync } from 'node:child_process';\n\n    const footprintKB = () => {\n      const out = execFileSync('vmmap', ['--summary', String(process.pid)]).\n  toString();\n      const [, n, unit] = out.match(/Physical footprint:\\s+([\\d.]+)([KMG])/);\n      return Number(n) * { K: 1, M: 1024, G: 1024 * 1024 }[unit];\n    };\n    const tick = () => new Promise((r) => setImmediate(r));\n    const sleep = (ms) => new Promise((r) => setTimeout(r, ms));\n\n    for (const n of [10, 100, 400, 1000]) {\n      const base = mkdtempSync(join(tmpdir(), 'fsw-'));\n      const dirs = Array.from({ length: n }, (_, i) => join(base, `d${i}`));\n      for (const d of dirs) mkdirSync(d);\n      const watchers = dirs.map((d) => watch(d, () => {}));\n      await sleep(500);\n      const before = footprintKB();\n      for (let i = 0; i \u003c 1000; i++) {\n        watchers[0].close();\n        watchers[0] = watch(dirs[0], () => {});\n        if (i % 20 === 0) await tick();\n      }\n      await sleep(500);\n      const growth = footprintKB() - before;\n      console.log(`${n} watchers open: +${(growth / 1024).toFixed(1)} MB after\n  1000 reopens (${(growth / 1000).toFixed(1)} KB per reopen)`);\n      for (const w of watchers) w.close();\n      await sleep(500);\n    }\n    process.exit(0);\n\n```\n\n### How often does it reproduce? Is there a required condition?\n\nEvery run on MacOS\n\n### What is the expected behavior? Why is that the expected behavior?\n\nI would expect physical memory usage to stay about flat.\n\n### What do you see instead?\n\n```\n 10 watchers open: +4.4 MB after 1000 reopens (4.5 KB per reopen)\n 100 watchers open: +11.8 MB after 1000 reopens (12.1 KB per reopen)\n 400 watchers open: +48.8 MB after 1000 reopens (50.0 KB per reopen)\n 1000 watchers open: +114.8 MB after 1000 reopens (117.6 KB per reopen)\n```\n\n\n### Additional information\n\nThis is fixed in libuv by https://github.com/libuv/libuv/pull/5283 (\"darwin:  release fsevents path allocations\"). `uv__fsevents_reschedule` rebuilds the shared FSEventStream from every watched path each time a watcher starts or stops, and did not release the path array and strings after a successful rebuild.\n\nThat commit is not in a libuv release yet. It merged after v1.53.0, so #66282 (update to libuv 1.53.0) does not include it. Could it be cherry-picked into  deps/uv , as was done for aabb7651de in #62561, and backported to v24.x?\n\nDownstream report: https://github.com/oxc-project/oxc-node/issues/906\n\nI used an AI coding assistant to help find the cause and draft this report. I ran the reproduction above myself on both versions listed and checked the libuv change against  src/unix/fsevents.c .\n","author":{"url":"https://github.com/howie-sola","@type":"Person","name":"howie-sola"},"datePublished":"2026-11-05T21:45:35Z","url":"https://github.com/nodejs/node/issues/67284"}