I tested running the test case 100k times on the AIX ci machine
and was unable to re-produce the error. Also it has not showed up
recently as flaky on the ci. I suggest we mark this
as un-flaky.
ref: https://github.com/nodejs/node/issues/50245#issuecomment-1924738357
PR-URL: https://github.com/nodejs/node/pull/51995
Reviewed-By: Richard Lau <rlau@redhat.com>
Reviewed-By: Michael Dawson <midawson@redhat.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
On Windows 2016 under high load further change events can be emitted
after writing the 5 bytes is reported. Updating the mtime of the file
can be reported as a separate change. This will increase the "before"
count, but not the "w1HookCount" since we removed the listener.
This makes the test keep the listeners until the end of the test.
Fixes: https://github.com/nodejs/node/issues/21425
PR-URL: https://github.com/nodejs/node/pull/32484
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Under high load 2 types of issues arise with this test.
* filesystem calls gets queued even when the 'sync' is used which leads
to async_hooks being called with the events of tmpdir clean or
initial file write after clean.
This is solved by counting all 'change' calls while making sure there
is no dependency of StatWatcher's on one another and the expected
changes are waited for.
* some events are getting lost with the current
clean->write->write_and_watch strategy. Specifically I observed the
file size going from 0 to 5 entirely skipping 3 even though the write
call was there (this happened reliably on -j128).
So I've changed the strategy to avoid additional write considering
this still tests the hooks correctly.
This may indicate some sort of bug in async_hooks though I'm not sure.
Closes: https://github.com/nodejs/node/issues/21425
PR-URL: https://github.com/nodejs/node/pull/30362
Fixes: https://github.com/nodejs/node/issues/21425
Reviewed-By: Stephen Belanger <admin@stephenbelanger.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Vladimir de Turckheim <vlad2t@hotmail.com>
test-statwatcher does not appear to be failing anymore in CI. Remove
"flaky" status for the test.
Closes: https://github.com/nodejs/node/issues/21425
PR-URL: https://github.com/nodejs/node/pull/29392
Fixes: https://github.com/nodejs/node/issues/21425
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: David Carlier <devnexen@gmail.com>
test-zlib.zlib-binding.deflate is failing continuously in our CI,
leaving us with 1% successful builds during the last 100 runs. This
commit marks the test as flaky while the issue is not resolved.
Ref: https://github.com/nodejs/node/issues/20907
PR-URL: https://github.com/nodejs/node/pull/20935
Refs: https://github.com/nodejs/node/issues/20907
Reviewed-By: Anatoli Papirovski <apapirovski@mac.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Since V8 5.9 V8 installs a default signal handler for some signals
when creating a default platform instance that prints a stack trace.
However, Node already does the same thing, so it would seem like the
two different stack traces would be printed; also, the V8 handler
would lead to a `SIGSEGV` under some circumstances, rather than
letting the abort continue normally.
Resolve this by disabling V8’s signal handler by default.
PR-URL: https://github.com/nodejs/node/pull/13985
Fixes: https://github.com/nodejs/node/issues/13865
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>