nodejs_24: fd tracking warnings ("opened in unmanaged mode twice") on aarch64-darwin due to libcxx 21 change

[mortyccp]

Nixpkgs version

• Unstable (26.11)

Describe the bug

When building packages that use worker_threads with sync file I/O (e.g. pnpm 11 installing dependencies), nodejs 24.15.0+ built by nixpkgs spams warnings:

(node:7511) Warning: File descriptor 46 opened in unmanaged mode twice
(node:7511) Warning: File descriptor 46 closed but not opened in unmanaged mode

Under heavy load (e.g. GHA runners), this leads to SIGKILL and build failures.

This is a build-inputs issue, not a nodejs code issue. Upstream node builds (static linking) cannot reproduce this.

Steps to reproduce

1. Create main.cjs:

const { Worker } = require('node:worker_threads');
const worker = new Worker(__dirname + '/worker.cjs');
worker.on('error', (e) => { console.error(e); process.exit(1); });
worker.on('exit', (c) => console.log('exited', c));

2. Create worker.cjs:

const { openSync, readSync, closeSync } = require('node:fs');
for (let i = 0; i < 800; i++) {
  const fd = openSync('/dev/null', 'r');
  const buf = Buffer.alloc(16);
  readSync(fd, buf, 0, 16, 0);
  closeSync(fd);
}
console.log('worker: 800 sync open/read/close done');

3. Run:

node --trace-warnings main.cjs

On the nixpkgs aarch64-darwin build of nodejs 24.15.0/24.16.0, this produces ~1599 warnings. On 24.14.1, 24.18.0, nodejs_22, and official nodejs.org builds, it produces 0 warnings.

Expected behaviour

No warnings. Sync file I/O in a worker thread should not trigger fd tracking warnings.

Screenshots

No response

Relevant log output

worker: 800 sync open/read/close done
(node:11967) Warning: File descriptor 14 closed but not opened in unmanaged mode
    at Object.<anonymous> (.../worker.cjs:8:3)
    at Module._compile (node:internal/modules/cjs/loader:1830:14)
(node:11967) Warning: File descriptor 14 opened in unmanaged mode twice
    at openSync (node:fs:561:18)
    at Object.<anonymous> (.../worker.cjs:5:14)
    at Module._compile (node:internal/modules/cjs/loader:1830:14)
... (1599 warnings total)

Additional context

Root cause

Comparing the build inputs of 24.14.1 (clean) and 24.15.0 (broken), the only meaningful difference is the libcxx version:

	24.14.1 (clean)	24.15.0 (broken)
libcxx	20.1.0+apple-sdk-26.0	21.1.6+apple-sdk-26.4

The bug requires all three of:

1. V8 13.6.233.17-node.48/.49 (shipped with node 24.15.0/24.16.0)
2. node_shared_libuv: true (nixpkgs dynamic linking)
3. libcxx 21.1.x (changed std::unordered_set ABI)

Removing any one of these eliminates the bug. This was verified across 4 builds:

Build	V8	libcxx	shared_libuv	warnings
nixpkgs 24.14.1	.44	20.1.0	true	0
nixpkgs 24.15.0	.48	21.1.6	true	1601
nixpkgs 26.4.0	14.6	21.1.6	true	0
official 24.15.0	.48	Xcode 16	false	0

Each clean build removes exactly one condition: 24.14.1 uses libcxx 20 (condition 3), 26.4.0 uses a different V8 (condition 1), and the official build uses static linking (condition 2).

This issue was originally reported in #525627 as a pnpm build failure, but it is a nodejs build issue.

Fix

Pinning the stdenv to llvmPackages_20.libcxxStdenv in pkgs/development/web/nodejs/v24.nix fixes the issue:

 buildNodejs = callPackage ./nodejs.nix {
   inherit openssl;
   python = python3;
+  stdenv = buildPackages.llvmPackages_20.libcxxStdenv;
 };

I reproduced the Hydra build of 24.15.0 locally using curl https://hydra.nixos.org/build/329352653/reproduce | bash, applied this one-line change, rebuilt, and confirmed 0 warnings. The rebuilt binary is identical except for using libcxx 20.1.x instead of 21.1.x — same V8, same dynamic libuv, same everything else.

System metadata

• system: "aarch64-darwin"
• host os: Darwin 25.3.0, macOS 26.3.1
• multi-user?: yes
• sandbox: no
• version: nix-env (Nix) 2.34.7+1
• channels(root): "nixpkgs"
• nixpkgs: /nix/store/gw7fxaw8z5szcqlzyzcnrshzi60zj664-source

Notify maintainers

@aduh95

---

Note for maintainers: Please tag this issue in your pull request description. (i.e. Resolves #ISSUE.)

I assert that this issue is relevant for Nixpkgs

• I assert that this is a bug and not a support request.
• I assert that this is not a duplicate of an existing issue.
• I assert that I have read the NixOS Code of Conduct and agree to abide by it.
• I assert that I have read the automation/AI policy and that this issue report complies with it.

Is this issue important to you?

Add a 👍 reaction to issues you find important.

[aduh95]

It's interesting, I was pretty sure that I tried pinning to llvmPackages_20 without seeing any improvements, but clearly I missed something. Thanks!

[aduh95]

Fixed by #536043

[mortyccp]

Fixed by #536043

I noticed the OfBorg build logs for #536043 showed failures. After investigating, I suspect the failure was due to the stdenv override being applied unconditionally (including on Linux), which likely caused cross-compilation issues or cache busts.

I've pushed a fix to only apply the libcxx pin for Darwin in my fork: mortyccp@a69eace

I applied this on top of the staging branch and tested the build locally on aarch64-darwin. The build succeeds, and the fd tracking warnings are completely gone (0 warnings, down from ~1600).

Question about OfBorg logs:
When looking at the logs in https://logs.ofborg.org/?attempt_id=-ofborg-&key=nixos%2Fnixpkgs.536043, I noticed the header says system: aarch64-linux but the log applies darwin-specific patches (e.g., darwin-plistbuddy-workaround.patch). Could you help me understand if OfBorg is cross-compiling to Darwin from a Linux builder? This is my first time interacting with OfBorg, and I want to ensure my Darwin-only override works correctly in CI.

[aduh95]

Limiting the change is a good idea indeed, doing that in #536336.

Question about OfBorg logs:

I don't know much about OfBorg, but I'm pretty sure it doesn't do any cross-compilation. If a darwin-specific patch has no effect on Linux, it makes sense to apply it so if an update makes it outdated, it can be detected quicker (I haven't checked whether that was the case here)

[mortyccp]

Root Cause: V8 std::hash ODR violation

The Bug

The trackUnmanagedFds warning is caused by an ODR violation in V8's hashing.h, not an LLVM/libc++ ABI bug. V8 injects a std::hash<T> specialization for any type T hashable via v8::base::hash<T> — including int. This overrides libc++'s identity std::hash<int> with V8's Thomas Wang scramble, but only in V8 internal translation units (which include hashing.h). Node's own TUs don't include hashing.h and get the identity hash. Both compile the same COMDAT hash-table symbols with different hash function bodies. The linker picks one copy per symbol, causing insert and erase to disagree on the hash of the same value.

Node's trackUnmanagedFds feature uses std::unordered_set<int> to track file descriptors. Due to the ODR violation, insert(fd) stores the entry under the scrambled hash, but erase(fd) looks it up under the identity hash — so erase() can't find the entry and emits the spurious "File descriptor N closed but not opened in unmanaged mode" warning.

Timeline

The bug was latent for 7 months, then triggered by an LLVM change, then fixed in V8:

Date	Event	Impact
2024-11-26	V8 commit 0d102357 introduces std::hash<T> partial specialization	Latent ODR violation — masked because libc++ uses explicit specializations for std::hash<int>, which always win over partial specializations in template resolution.
2025-06-10	LLVM PR #140407 merges — refactors libc++ std::hash from explicit specializations to a SFINAE-based __hash_impl	Trigger — std::hash<int> is now a partial specialization. V8's std::hash<T> (also a partial specialization, but more constrained via a requires clause) wins template resolution in TUs that include hashing.h. The ODR violation becomes active.
2025-06-11	Chromium discovers test failures (NetworkInterfaceChangeListenerMojomTraitsTest.OnlineLinks) after rolling the libc++ change	Bug reported — Chromium bug 424006386. Investigation reveals V8's std::hash specialization overrides std::hash<int>.
2025-06-24	V8 commit 65ce14d8 removes the std::hash<T> partial specialization	Fixed — V8's internal code now uses base::hash<T> explicitly. The libc++ roll (#140407) proceeds forward successfully.

Why the bug only manifests with LLVM 21+: Before #140407, libc++ defined std::hash<int> as an explicit specialization, which always wins over V8's partial specialization — the ODR violation was latent. After #140407, both are partial specializations, and V8's is more constrained (uses a requires clause), so it wins in V8 TUs — the ODR violation becomes active.

nixpkgs build timeline (Darwin aarch64)

All three Node 24.x releases ship V8 13.6.233.17 with the std::hash override. The difference between passing and failing is the LLVM/libc++ version in the nixpkgs stdenv:

Date	Node version	Build	Status	Notes
2026-04-23	24.14.1	327049751	✅ Passed	LLVM 20 — ODR violation latent (explicit specializations win)
2026-06-17	24.15.0	329352653	❌ Failed	LLVM 21 — #140407 triggered the ODR violation; trackUnmanagedFds test fails

Scope

• Only Node 24 is affected — the std::hash override was introduced in V8 13.x (0d102357) and is present in Node 24's V8 13.6.233 (hashing.h#L364-L369). Node 22 (V8 12.4) and Node 20 do not have this code. Node 25 (V8 14.1) and Node 26 (V8 14.6) already include the upstream fix (65ce14d8) and are not affected.
• All platforms have the ODR violation, but the bug only manifests on Darwin with LLVM 21 (where the linker picks the scrambled copy). The ODR violation is undefined behavior regardless of whether it manifests.

Upstream Fix

Introduced in V8 commit 0d102357, fixed in V8 commit 65ce14d8 — Chromium bug 424006386.

The upstream fix removes the std::hash<T> specialization and changes V8's internal code to use base::hash<T> explicitly (3 files: hashing.h, profile-generator.h, canonical-types.h). Node.js hasn't yet picked up this fix in any 24.x release.

Recommended Fix

Backport the upstream V8 fix as a patch in v24.nix (all 3 files). This fixes the root cause on all platforms and removes the need for the llvmPackages_20 pin.

References

• Upstream V8 fix: v8/v8@65ce14d
• Upstream V8 bug: https://issues.chromium.org/issues/424006386
• Introduced in: v8/v8@0d10235
• Node 24 hashing.h override: https://github.com/nodejs/node/blob/v24.x/deps/v8/src/base/hashing.h#L364-L369
• LLVM (trigger): [libc++] Simplify the implementation of std::hash llvm/llvm-project#140407
• Hydra build 24.15.0 (failed): https://hydra.nixos.org/build/329352653
• Hydra build 24.14.1 (passed): https://hydra.nixos.org/build/327049751