Under peculiar system load conditions, the profiler thread
does not get enough CPU slices to perform the sampling.
Improve the interaction between worker and parent thread
by performing a large disc read, which is a better blend of
CPU and I/O bound work, than earlier versions.
This produces x10 more samples than the existing one,
in 10 iterations, as opposed to 1024.
Also capture worker error situations to improve debugging
Refs: https://github.com/nodejs/node/issues/26401#issuecomment-597438516
PR-URL: https://github.com/nodejs/node/pull/32190
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: James M Snell <jasnell@gmail.com>
`test-inspector-multisession-ws` and `test-inspector-break-when-eval`
will be affected by an upstream bug when we upgrade V8 to 8.1. The bug
is caused when the Inspector sets a pause at the start of a function
compiled with `CompileFunctionInContext`, but that function hasn't been
executed yet.
On both tests, this issue is triggered by pausing while in C++ executing
LookupAndCompile, which is called by requiring internal modules while
running `console.log`. To eliminate this issue in both tests, we add an
extra `console.log` to ensure we only pause we required all internal
modules we need. On `test-inspector-break-when-eval`, we also need to
start the child process with `--inspect-brk` instead of `--inspect` to
ensure the test is predictable (this test would occasianlly fail on
slower machines, when console.log doesn't run fast enough to finish
after emitting `Runtime.consoleAPICalled` and before the parent process
sending `Runtime.evaluate` message.
Ref: https://bugs.chromium.org/p/v8/issues/detail?id=10287
PR-URL: https://github.com/nodejs/node/pull/32234
Refs: https://bugs.chromium.org/p/v8/issues/detail?id=10287
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
OpenSSL s_server accepts port 0 as an indicator to use an open port
provided by the operating system. Use that instead of common.PORT in the
test.
Remove 500ms delay added in 8e461673c4.
Hopefully the race condition in OpenSSL s_server has been fixed and/or
the change to port 0 means that the server is listening by the time
the ACCEPT text is printed and the setTimeout() is no longer necessary.
PR-URL: https://github.com/nodejs/node/pull/32024
Reviewed-By: Ben Coe <bencoe@gmail.com>
Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
When dgram socket implicit binding fails, an attempt is made to
clean up the send queue. This was originally implemented using
an 'error' handler that performed cleanup and then emitted a
fake error, which concealed the original error. This was done
to prevent cases where the same error was emitted twice. Now
that the errorMonitor event is available, use that to perform
the cleanup without impacting the actual error handling.
PR-URL: https://github.com/nodejs/node/pull/31958
Refs: https://github.com/nodejs/help/issues/2484
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
If terminating the process with ctrl-c / SIGINT, prints a JS stacktrace
leading up to the currently executing code.
The feature would be enabled under option `--trace-sigint`.
Conditions of no stacktrace on sigint:
- has (an) active sigint listener(s);
- main thread is idle (i.e. uv polling), a message instead of stacktrace
would be printed.
PR-URL: https://github.com/nodejs/node/pull/29207
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Christopher Hiller <boneskull@boneskull.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
This completely refactors the `expectsError` behavior: so far it's
almost identical to `assert.throws(fn, object)` in case it was used
with a function as first argument. It had a magical property check
that allowed to verify a functions `type` in case `type` was passed
used in the validation object. This pattern is now completely removed
and `assert.throws()` should be used instead.
The main intent for `common.expectsError()` is to verify error cases
for callback based APIs. This is now more flexible by accepting all
validation possibilites that `assert.throws()` accepts as well. No
magical properties exist anymore. This reduces surprising behavior
for developers who are not used to the Node.js core code base.
This has the side effect that `common` is used significantly less
frequent.
PR-URL: https://github.com/nodejs/node/pull/31092
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
ERR_INVALID_ARG_TYPE is the most common error used throughout the
code base. This improves the error message by providing more details
to the user and by indicating more precisely which values are allowed
ones and which ones are not.
It adds the actual input to the error message in case it's a primitive.
If it's a class instance, it'll print the class name instead of
"object" and "falsy" or similar entries are not named "type" anymore.
PR-URL: https://github.com/nodejs/node/pull/29675
Reviewed-By: Rich Trott <rtrott@gmail.com>
The resolution for the main entry point may fail when the resolution
requires a preloaded module to be executed first (for example when
adding new extensions to the resolution process). Silently skipping
such failures allow us to defer the resolution as long as needed
without having any adverse change (since the main entry point won't
resolve anyway if it really can't be resolved at all).
PR-URL: https://github.com/nodejs/node/pull/30336
Reviewed-By: Guy Bedford <guybedford@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
test-http-max-http-headers seems to run fine in parallel, even with
`tools/test.py -j 96 --repeat 192
test/parallel/test-http-max-http-headers.js`.
The same applies to `test-set-http-max-http-headers.js` which (as
written) depends on `test-http-max-http-headers.js` being in the same
directory. So that is being moved too.
PR-URL: https://github.com/nodejs/node/pull/30712
Reviewed-By: David Carlier <devnexen@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
In test-http-max-http-headers, a comment asks why we are subtracting 32
from the length of the invalid-length-by-1 headers instead of just 1.
Subtracting 1 seems to be correct and works.
PR-URL: https://github.com/nodejs/node/pull/30712
Reviewed-By: David Carlier <devnexen@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Change the test to be robust in slow environments and move to parallel.
The previous version of the test failed for me in parallel with just two
or four simultaneous versions running. This version passes 96
simultaneous versions running, but still fails as designed if the
request writes fail to prevent the request timeout from occurring.
PR-URL: https://github.com/nodejs/node/pull/30677
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
test-http-server-consumed-timeout has code to that causes it to be
skipped on busy machines. Instead, use an exponential backoff for the
timeout if the machine is busy.
PR-URL: https://github.com/nodejs/node/pull/30677
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Replace setTimeout() with setImmediate() in
test-stream-writable-clear-buffer. The test still fails in Node.js 8.6.0
(if you comment out the `common` module, since it uses BigInts and those
aren't supported in 8.6.0).
PR-URL: https://github.com/nodejs/node/pull/30561
Reviewed-By: Denys Otrishko <shishugi@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
