- Generate and use a list of suppressions that reduce noisiness for
known (non-)issues.
- Use `--zero-fill-buffers` for tests, as they sometimes use
`Buffer.allocUnsafe()` and valgrind reports that as usage
of uninitialized memory.
PR-URL: https://github.com/nodejs/node/pull/25498
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Calling env->EmitProcessEnvWarning() prevents additional warnings
from being set it should therefore be called only if a warning will
emit.
PR-URL: https://github.com/nodejs/node/pull/25575
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/25441
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
PR-URL: https://github.com/nodejs/node/pull/25507
Reviewed-By: Daniel Bevenius <daniel.bevenius@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: James M Snell <jasnell@gmail.com>
This commit updates the named curves P-192 (prime192v1), and secp192k1
to 256 bit versions.
The motivation for this is that in Red Hat Enterprise Linux (RHEL) all
ECC curves < 224 bits are removed from OpenSSL provided by the system.
I'm not sure if other distributions do this but these 256 bit curves are
availalbe in OpenSSL 1.1.0j (current version on master) and OpenSSL
1.1.1 so as far as I can tell it should be safe change to make.
PR-URL: https://github.com/nodejs/node/pull/25564
Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
This commit updates option ciphers from 'RC4' to 'no-such-cipher' in
test/parallel/test-tls-handshake-error.js.
The motivation for this change is that this test is verifying that a
'no ciphers match' error be thrown, but 'RC4' might be among the ciphers
supported by the OpenSSL version when dynamically linking. I ran into
this specific issue when dynamically linking against OpenSSL 1.1.1 on
RHEL8 using https://github.com/nodejs/node/pull/25381.
PR-URL: https://github.com/nodejs/node/pull/25534
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
I was implementing a Writable stream and misunderstood `decodeStrings`
to mean 'will decode `Buffer`s into `string`s before calling `_write`'.
This change adds a little more detail to the description of
`decodeStrings` to clarify its effect on a Writable stream & what gets
passed to `_write`.
Changing the name of the option to `encodeStrings` would make it much
easier to understand, but the name was chosen in 2012 and the option
used in many projects (22k mentions of 'decodeStringsr in JS projects in
GitHub). Deprecating the old name & rolling out a replacement is beyond
my capabilities as a first-time contributor.
PR-URL: https://github.com/nodejs/node/pull/25468
Fixes: https://github.com/nodejs/node/issues/25464
Reviewed-By: Anna Henningsen <anna@addaleax.net>
If specified, and only when a socket is created internally, the option
will make `socket.setTimeout()` to be called on the created socket with
the given timeout.
This is consistent with the `timeout` option of `net.connect()` and
prevents the `timeout` option of the `https.Agent` from being ignored
when a socket is created.
PR-URL: https://github.com/nodejs/node/pull/25517
Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
Reviewed-By: Roman Reiss <me@silverwind.io>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
In parallel/test-fs-read-stream-concurrent-reads.js the number
of data chunks used is being tested when few concurrent reads
are performed. The number of chunks can fluctuate based on the
number of concurrent reads as well as the data that was read in
one shot. Accommodate these variations in the test.
Fixes: https://github.com/nodejs/node/issues/22339
PR-URL: https://github.com/nodejs/node/pull/25415
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/25547
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Anto Aravinth <anto.aravinth.cse@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
v11.6.0 ended up shipping with an npm version `6.5.0-next.0`.
This test should avoid it happening in the future.
PR-URL: https://github.com/nodejs/node/pull/25538
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Minwoo Jung <minwoo@nodesource.com>
Coverage report for src/node_i18n.cc shows that the
Has() method is not covered. This test adds coverage
for that method.
PR-URL: https://github.com/nodejs/node/pull/25428
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Currently the following compiler warnings is generated:
../src/node_report.cc:778:43:
warning: format specifies type 'unsigned long' but the argument has
type 'rlim_t' (aka 'unsigned long long') [-Wformat]
snprintf(buf, sizeof(buf), "%lu", limit.rlim_max);
~~~ ^~~~~~~~~~~~~~
%llu
1 warning generated.
This commit changes the format specifier to $llu.
PR-URL: https://github.com/nodejs/node/pull/25557
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Minwoo Jung <minwoo@nodesource.com>
Currently, test-cli-node-print-help uses common.hasFipsCrypto to
determine if the test should check for the existence of FIPS related
options (--enable-fips, and --force-fips). The FIPS options are
available when node has been compiled against an OpenSSL library with
FIPS support in which case the test would verify that these options
are available. But by using crypto.fips (which uses crypto.getFips())
this would only be checked when fips has been enabled, but these
options are available regardless if FIPS is enabled or disabled.
This commit updates the test to use fipsMode from config to determine
if the FIPS options existence should be checked.
PR-URL: https://github.com/nodejs/node/pull/25510
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
The fallback should only be taken for a null prototype. If an
iterable data type (e.g., Array) has a prototype without
`Symbol.iterator`, just try the best to visualize it as object.
PR-URL: https://github.com/nodejs/node/pull/25457
Fixes: https://github.com/nodejs/node/issues/25451
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Anto Aravinth <anto.aravinth.cse@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Only use the amount of data that was actually read from the test file.
Otherwise, there is a small risk of getting false positives, and
generally reading uninitialized memory makes using automated
memory error detection tools harder.
PR-URL: https://github.com/nodejs/node/pull/25475
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
One test per each API, so that additional tests in future are modular.
test/common/report.js contain common functions that tests leverage.
PR-URL: https://github.com/nodejs/node/pull/22712
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Michael Dawson <Michael_Dawson@ca.ibm.com>
Reviewed-By: Vse Mozhet Byt <vsemozhetbyt@gmail.com>
a separate section added for node-report at top level
main documentation added to doc/api/report.md
API documentation added to doc/api/process.md
PR-URL: https://github.com/nodejs/node/pull/22712
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Michael Dawson <Michael_Dawson@ca.ibm.com>
Reviewed-By: Vse Mozhet Byt <vsemozhetbyt@gmail.com>
Make node-report part of core runtime because:
1. When enabled, node-report significantly helps root cause various
types of problems, including support issues sent to the various repos
of the Node.js organization.
2. The requirement of explicitly adding the dependency to node-report
in user applications often represents a blocker to adoption.
Major deviation from the module version of the node-report is that the
report is generated in JSON format, as opposed to human readable text.
No new functionalities have been added, changes that are required for
melding it as a built-in capability has been affected on the module
version of node-report (https://github.com/nodejs/node-report)
Co-authored-by: Bidisha Pyne <bidipyne@in.ibm.com>
Co-authored-by: Howard Hellyer <hhellyer@uk.ibm.com>
Co-authored-by: Jeremiah Senkpiel <fishrock123@rocketmail.com>
Co-authored-by: Julian Alimin <dmastag@yahoo.com>
Co-authored-by: Lakshmi Swetha Gopireddy <lakshmigopireddy@in.ibm.com>
Co-authored-by: Manusaporn Treerungroj <m.treerungroj@gmail.com>
Co-authored-by: Michael Dawson <michael_dawson@ca.ibm.com>
Co-authored-by: Richard Chamberlain <richard_chamberlain@uk.ibm.com>
Co-authored-by: Richard Lau <riclau@uk.ibm.com>
Co-authored-by: Sam Roberts <vieuxtech@gmail.com>
Co-authored-by: Vipin Menon <vipinmv1@in.ibm.com>
PR-URL: https://github.com/nodejs/node/pull/22712
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Michael Dawson <Michael_Dawson@ca.ibm.com>
Reviewed-By: Vse Mozhet Byt <vsemozhetbyt@gmail.com>
This PR adds the ability to provide Workers with their own
execArgv flags in replacement of the main thread's execArgv. Only
per-Isolate/per-Environment options are allowed. Per-Process options
and V8 flags are not allowed. Passing an empty execArgv array will
reset per-Isolate and per-Environment options of the Worker to their
defaults. If execArgv option is not passed, the Worker will get
the same flags as the main thread.
Usage example:
```
const worker = new Worker(__filename, {
execArgv: ['--trace-warnings'],
});
```
PR-URL: https://github.com/nodejs/node/pull/25467
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/25544
Reviewed-By: Vse Mozhet Byt <vsemozhetbyt@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Reduce the time it takes to run test/pummel/test-hash-seed by switching
from spawnSync() to spawn(). On my computer, this reduces the runtime
from about 80 seconds to about 40 seconds. This test is not (yet) run
regularly on CI, but when it was run recently, it timed out.
PR-URL: https://github.com/nodejs/node/pull/25522
Reviewed-By: Ali Ijaz Sheikh <ofrobots@google.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Minwoo Jung <minwoo@nodesource.com>
Replace min() function with Math.min(...).
PR-URL: https://github.com/nodejs/node/pull/25522
Reviewed-By: Ali Ijaz Sheikh <ofrobots@google.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Minwoo Jung <minwoo@nodesource.com>
test/pummel/test-keep-alive.js requires `wrk` to be installed. Check if
it is, and skip the test if it isn't.
This is yet another step in preparation for running pummel tests in CI
daily.
PR-URL: https://github.com/nodejs/node/pull/25516
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: James M Snell <jasnell@gmail.com>
This reverts commit f216d5bbb1.
Seems like it breaks the nightly job so reverting until
we figure that out.
PR-URL: https://github.com/nodejs/node/pull/25543
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
This enables code loaded via the module system to be checked for
integrity to ensure the code loaded matches expectations.
PR-URL: https://github.com/nodejs/node/pull/23834
Reviewed-By: Guy Bedford <guybedford@gmail.com>
Reviewed-By: Vladimir de Turckheim <vlad2t@hotmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
- DEFAULT_ECDH_CURVE default changed to 'auto' for 10.0.0
- ecdhCurve parameter allowed multiple values and 'auto' from 9.0.0
PR-URL: https://github.com/nodejs/node/pull/25502
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Currently, while FIPS is not supported yet for this release there might
be an option to dynamically link against a FIPS compatible OpenSSL
version.
This commit fixes the compiler errors.
PR-URL: https://github.com/nodejs/node/pull/25412
Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
This commit introduces a new configuration flag named
--openssl-is-fips which is intended to be used when linking against
an OpenSSL library that is FIPS compatible.
The motivation for this is that Red Hat Enterprise Linux 8 (RHEL8)
comes with OpenSSL 1.1.1 and includes FIPS support, and we would
like to be able to dynamically link against this version and also have
FIPS features enabled in node, like would be done when statically
linking and using the --openssl-fips flag.
The suggestion here is to introduce a new flag:
$ ./configure --help
...
--openssl-is-fips specifies that the shared OpenSSL version is FIPS
compatible
This flag could be used in combination with the shared-openssl flag:
$ ./configure --shared-openssl ---openssl-is-fips
This will enable FIPS support in node and the runtime flags will be
availalbe to enable FIPS (--enable-fips, --force-fips).
PR-URL: https://github.com/nodejs/node/pull/25412
Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Original commit message 9365d09:
[coverage] Rework continuation counter handling
This changes a few bits about how continuation counters are handled.
It introduces a new mechanism that allows removal of a continuation
range after it has been created. If coverage is enabled, we run a first
post-processing pass on the AST immediately after parsing, which
removes problematic continuation ranges in two situations:
1. nested continuation counters - only the outermost stays alive.
2. trailing continuation counters within a block-like structure are
removed if the containing structure itself has a continuation.
R=bmeurer@chromium.org, jgruber@chromium.org, yangguo@chromium.org
Bug: v8:8381, v8:8539
Change-Id: I6bcaea5060d8c481d7bae099f6db9f993cc30ee3
Reviewed-on: https://chromium-review.googlesource.com/c/1339119
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58443}
Refs: v8/v8@9365d09
Original commit message aac2f8c:
[coverage] Filter out singleton ranges that alias full ranges
Block coverage is based on a system of ranges that can either have
both a start and end position, or only a start position (so-called
singleton ranges). When formatting coverage information, singletons
are expanded until the end of the immediate full parent range. E.g.
in:
{0, 10} // Full range.
{5, -1} // Singleton range.
the singleton range is expanded to {5, 10}.
Singletons are produced mostly for continuation counters that track
whether we execute past a specific language construct.
Unfortunately, continuation counters can turn up in spots that confuse
our post-processing. For example:
if (true) { ... block1 ... } else { ... block2 ... }
If block1 produces a continuation counter, it could end up with the
same start position as the else-branch counter. Since we merge
identical blocks, the else-branch could incorrectly end up with an
execution count of one.
We need to avoid merging such cases. A full range should always take
precedence over a singleton range; a singleton range should never
expand to completely fill a full range. An additional post-processing
pass ensures this.
Bug: v8:8237
Change-Id: Idb3ec7b2feddc0585313810b9c8be1e9f4ec64bf
Reviewed-on: https://chromium-review.googlesource.com/c/1273095
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56531}
Refs: v8/v8@aac2f8c
deps: V8: backport 47d34a3
Original commit message:
Revert "[coverage] change block range to avoid ambiguity."
This reverts commit 471fef0469d04d7c487f3a08e81f3d77566a2f50.
Reason for revert: A more general fix incoming at https://crrev.com/c/1273095.
Original change's description:
> [coverage] change block range to avoid ambiguity.
>
> By moving the block range end to left of closing bracket,
> we can avoid ambiguity where an open-ended singleton range
> could be both interpreted as inside the parent range, or
> next to it.
>
> R=<U+200B>verwaest@chromium.org
>
> Bug: v8:8237
> Change-Id: Ibc9412b31efe900b6d8bff0d8fa8c52ddfbf460a
> Reviewed-on: https://chromium-review.googlesource.com/1254127
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#56347}
TBR=yangguo@chromium.org,neis@chromium.org,verwaest@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:8237
Change-Id: I39310cf3c2f06a0d98ff314740aaeefbfffc0834
Reviewed-on: https://chromium-review.googlesource.com/c/1273096
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56513}
Refs: 47d34a317e
PR-URL: https://github.com/nodejs/node/pull/25429
Reviewed-By: Yang Guo <yangguo@chromium.org>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Call `Environment::Exit()` rather than the process-wide
`exit()` function, since JS exceptions generally only affect
the current JS engine instance.
PR-URL: https://github.com/nodejs/node/pull/25472
Reviewed-By: Daniel Bevenius <daniel.bevenius@gmail.com>
Reviewed-By: Minwoo Jung <minwoo@nodesource.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Anatoli Papirovski <apapirovski@mac.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
This makes sure that `StopTracingAgent()` is always called
before tearing down the `tracing::Agent`,
since previously its destructor might have tried to access the
agent, which would be destroyed by the (earlier) `Dispose()` call.
PR-URL: https://github.com/nodejs/node/pull/25472
Reviewed-By: Daniel Bevenius <daniel.bevenius@gmail.com>
Reviewed-By: Minwoo Jung <minwoo@nodesource.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Anatoli Papirovski <apapirovski@mac.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
* Use port 0 instead of `common.PORT`.
* Use `//` for comments, capitalize comments, and add punctuation.
PR-URL: https://github.com/nodejs/node/pull/25485
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
