[v22.x backport] deps: update libuv to 1.51.0

[juanarbol]

PR-URL: #58124
Backport-PR-URL: #57316
Reviewed-By: Anna Henningsen [email protected]
Reviewed-By: Colin Ihrig [email protected]
Reviewed-By: Rafael Gonzaga [email protected]
Reviewed-By: Santiago Gimeno [email protected]
Reviewed-By: Juan José Arboleda [email protected]
Reviewed-By: Antoine du Hamel [email protected]

---

I had 0 problems locally, I'll kick a CI

[nodejs-github-bot]

Review requested:

• @nodejs/security-wg

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/65574/

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/65590/

[richardlau]

This still has the same CI failures as #56616 (comment). Most likely this version of libuv has broken something on 32-bit Windows. We no longer build on 32-bit Windows for Node.js 23 which is why this would not have been noticed until attempting to land on Node.js 22 (where we still test and release on 32-bit Windows).

cc @nodejs/libuv @nodejs/platform-windows

[bnoordhuis]

I only see this error. Are there more?

 + 'ERR_FS_EISDIR' - 'ERR_FS_CP_EINVAL' 

That's node's wrapper around uv_fs_copyfile(), right? The new error code seems more appropriate, doesn't it?

[targos]

On 32-bit Windows, the error is:

> python tools\test.py --mode=release --flaky-tests=dontcare --run=0,4 --measure-flakiness 9 -p tap --logfile test.tap default pummel Can't determine the arch of: 'C:\workspace\node-test-binary-windows-js-suites\node\Release\node.exe' 

Coming from

node/tools/test.py

Lines 1708 to 1713 in 2a6f908

	archEngineContext=Execute([vm, "-p", "process.arch"], context)
	vmArch=archEngineContext.stdout.rstrip()
	ifarchEngineContext.exit_code!=0orvmArch=="undefined":
	print("Can't determine the arch of: '%s'"%vm)
	print(archEngineContext.stderr.rstrip())
	continue

[juanarbol]

I'll spin a VM and inspect. Please do not expect anything, I do this on my spare time

[juanarbol]

Can anyone from @nodejs/build help me out setting up the box? I haven't be able to setup visual studio, not even with Boxstarter. Apparently 32bits vs stuff is not longer distributed or something.

Refs: https://github.com/nodejs/node/blob/main/BUILDING.md#option-3-automated-install-with-boxstarter

[anonrig]

Cc @nodejs/platform-windows

[juanarbol]

Most likely this version of libuv has broken something on 32-bit Windows.

Not quite sure, libuv has jobs for Win32¹; any idea about how should I debug this one?

Footnotes

1. https://github.com/libuv/libuv/blob/v1.x/.github/workflows/CI-win.yml#L24, https://github.com/libuv/libuv/blob/v1.x/.github/workflows/CI-win.yml#L26↩

[richardlau]

On 32-bit Windows, the error is:

> python tools\test.py --mode=release --flaky-tests=dontcare --run=0,4 --measure-flakiness 9 -p tap --logfile test.tap default pummel Can't determine the arch of: 'C:\workspace\node-test-binary-windows-js-suites\node\Release\node.exe' 

Coming from

node/tools/test.py

Lines 1708 to 1713 in 2a6f908

	archEngineContext=Execute([vm, "-p", "process.arch"], context)
	vmArch=archEngineContext.stdout.rstrip()
	ifarchEngineContext.exit_code!=0orvmArch=="undefined":
	print("Can't determine the arch of: '%s'"%vm)
	print(archEngineContext.stderr.rstrip())
	continue

FWIW I downloaded binary.tgz from https://ci.nodejs.org/job/node-compile-windows/60791/nodes=win-vs2022-x86/ (from https://ci.nodejs.org/job/node-test-pull-request/65590/). And running node -p process.arch gives ia32:

C:\Users\rlau\Downloads\test>node -p process.versions{ node: '22.14.1-pre', acorn: '8.14.0', ada: '2.9.2', amaro: '0.3.0', ares: '1.34.4', brotli: '1.1.0', cjs_module_lexer: '1.4.1', cldr: '46.0', icu: '76.1', llhttp: '9.2.1', modules: '127', napi: '10', nbytes: '0.1.1', ncrypto: '0.0.1', nghttp2: '1.64.0', nghttp3: '1.6.0', ngtcp2: '1.10.0', openssl: '3.0.15+quic', simdjson: '3.10.1', simdutf: '6.0.3', sqlite: '3.47.2', tz: '2024b', undici: '6.21.1', unicode: '16.0', uv: '1.50.0', uvwasi: '0.0.21', v8: '12.4.254.21-node.22', zlib: '1.3.0.1-motley-82a5fec'}C:\Users\rlau\Downloads\test>node -p process.archia32C:\Users\rlau\Downloads\test>

So maybe this is something more subtle affecting Node.js being executed by the Python-based test runner (either not capturing stdout or exiting with a non zero exit code)?

[juanarbol]

So maybe this is something more subtle affecting Node.js being executed by the Python-based test runner (either not capturing stdout or exiting with a non zero exit code)?

Maybe, I tried to move the "binary artifacts" into a fresh Node.js repo in my VM; tests are running "normally". It was as simple as copying the "binary/Release" folder and paste it into "node/out/"; tests seems ok

PS C:\Users\jj\Desktop\node> python tools\test.py --mode=release --flaky-tests=dontcare --run=0,4 --measure-flakiness 9 -p tap --logfile test.tap default pummel Skipping pseudo-tty tests, as pseudo terminals are not available on Windows. TAP version 13 1..1051 ok 1 async-hooks/test-embedder.api.async-resource.runInAsyncScope --- duration_ms: 54.00200 ... ok 2 async-hooks/test-async-local-storage-promises --- duration_ms: 63.30900 ... ok 3 async-hooks/test-async-local-storage-async-await --- duration_ms: 67.99700 ... ok 4 async-hooks/test-async-wrap-providers --- duration_ms: 76.53700 ... ok 5 async-hooks/test-async-local-storage-enter-with --- duration_ms: 80.59000 ... ok 6 async-hooks/test-async-local-storage-http --- duration_ms: 95.92200 ... 

Just FYI, I haven't been able to compile Node.js in that VM; that's why I'm using the artefacts.

Re-ran the the win job with a print of the command addition. https://ci.nodejs.org/job/node-test-commit-windows-fanned/69059/

[RafaelGSS]

Hi @juanarbol, just a FYI, I'll issue a v22 release soon this week, and this PR might not go due to red-CI.

[juanarbol]

Hi @juanarbol, just a FYI, I'll issue a v22 release soon this week, and this PR might not go due to red-CI.

I'm ok tho, I don't have the bandwidth to have a deadline or something; I'll keep working on this one on my spare time.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/67033/

[juanarbol]

Just FYI, I've introduced 78eb583fd3cf55fa6e08d2bcf2e528eb0709a6fd as seems required (see #58124 (comment))

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/67038/

[juanarbol]

Just for the record, I think this fixed thew win32bits issues. libuv/libuv#4679

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/67103/

[github-actions]

Failed to start CI

 ⚠ Commits were pushed since the last approving review: ⚠ - test: reduce iteration count in test-child-process-stdout-flush-exit ⚠ - deps: update libuv to 1.51.0 ✘ Refusing to run CI on potentially unsafe PR

https://github.com/nodejs/node/actions/runs/15259273781

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/67125/

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/67129/

[juanarbol]

Humble ping to @nodejs/collaborators. Coverage is failing due to OOM, and It has failed due to OOM 3 times in a row. Is there anything I can/should be doing?

[juanarbol]

Landed in cb39e4c...e397980 🎉

[aduh95]

Humble ping to @nodejs/collaborators

FWIW landing stuff on staging branches is not up to Collaborators, those are managed by the Release WG – typically, whoever prepares the next 22.x release would have taken care of landing it.

[juanarbol]

those are managed by the Release WG

I'm a releaser.

[richardlau]

FWIW #58124 hasn't gone out in a current (i.e. v24.x) release yet, so landing this on v22.x-staging was a bit premature.

[juanarbol]

FWIW #58124 hasn't gone out in a current (i.e. v24.x) release yet, so landing this on v22.x-staging was a bit premature.

I'll be more careful next time, I was rushing landing this particular PR due to CI flakes, I don't wanna fight it back again (with the CI); having to re-run CI cuz' target branch diverged is a waste of time.

At least that helped pinpointing a flake. I'm sorry.

[aduh95]

According to #58587, the libuv updagrade is causing compilation problems on some platforms

[thunder-coding]

According to #58587, the libuv updagrade is causing compilation problems on some platforms

It's not the libuv update that broke builds for Android, but rather it was the ndk r28. The error in the PR does not happen with NDK r27c. Also anyways what is the usual process of backporting commits to the LTS branches? Are PRs accepted by external contributors for LTS branches (all PRs I see to lts staging branch are from core maintainers)?

[aduh95]

@thunder-coding backport PRs are needed only for changes that do not land cleanly (i.e. either git conflict or red CI). For most cases, there's no action to take to see the change land on Active LTS branches, releasers will cherry-pick the commit as part of the usual release preparation steps after it's been on a Current release for some time.
Is my understanding correct that we should release a version with the libuv update and not #58587? Let's take this discussion somewhere else (e.g. on your PR) as the whole collaborator team has been pinged on that one, every additional comment is sending notifications to a hundred folks.