This patch implements --cpu-prof-interval to specify the sampling
interval of the CPU profiler started by --cpu-prof from the command
line. Also adjust the interval to 100 in test-cpu-prof.js to make
the test less flaky - it would fail if the time taken to finish
the workload is smaller than the sampling interval, which was
more likely on powerful machines when the interval was 1000.
PR-URL: https://github.com/nodejs/node/pull/27535
Reviewed-By: Jan Krems <jan.krems@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Franziska Hinkelmann <franziska.hinkelmann@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
To improve the integration of `--cpu-prof` with workers, this patch
splits `--cpu-prof-path` into `--cpu-prof-dir` and `--cpu-prof-name`,
so when a worker is launched from a thread that enables
`--cpu-prof`, if the parent thread sets `--cpu-prof-dir`, then the
profile of both thread would be generated to the specified directory.
If they end up specifying the same `--cpu-prof-name` the behavior
is undefined the last profile will overwritten the first one.
PR-URL: https://github.com/nodejs/node/pull/27306
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
In the code base the word `report` is almost only used to refer to
the diagnostic report when it's a noun, and it's programmable
interface `process.report()` it not prefixed, so `report` should be
unambiguous enough to use without `diagnostic`.
PR-URL: https://github.com/nodejs/node/pull/27312
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
This patch introduces a CLI flag --cpu-prof that starts the V8
CPU profiler on start up, and ends the profiler then writes the
CPU profile before the Node.js instance (on the main thread or
the worker thread) exits. By default the profile is written to
`${cwd}/CPU.${yyyymmdd}.${hhmmss}.${pid}.${tid}.${seq}.cpuprofile`.
The patch also introduces a --cpu-prof-path flag for the user
to specify the path the profile will be written to.
Refs: https://github.com/nodejs/node/issues/26878
PR-URL: https://github.com/nodejs/node/pull/27147
Reviewed-By: Anna Henningsen <anna@addaleax.net>
This adds a flag to define the default behavior for unhandled
rejections. Three modes exist: `none`, `warn` and `strict`. The first
is going to silence all unhandled rejection warnings. The second
behaves identical to the current default with the excetion that no
deprecation warning will be printed and the last is going to throw
an error for each unhandled rejection, just as regular exceptions do.
It is possible to intercept those with the `uncaughtException` hook
as with all other exceptions as well.
This PR has no influence on the existing `unhandledRejection` hook.
If that is used, it will continue to function as before.
PR-URL: https://github.com/nodejs/node/pull/26599
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Matheus Marchini <mat@mmarchini.me>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Reviewed-By: Сковорода Никита Андреевич <chalkerx@gmail.com>
Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com>
This introduces TLS1.3 support and makes it the default max protocol,
but also supports CLI/NODE_OPTIONS switches to disable it if necessary.
TLS1.3 is a major update to the TLS protocol, with many security
enhancements. It should be preferred over TLS1.2 whenever possible.
TLS1.3 is different enough that even though the OpenSSL APIs are
technically API/ABI compatible, that when TLS1.3 is negotiated, the
timing of protocol records and of callbacks broke assumptions hard-coded
into the 'tls' module.
This change introduces no API incompatibilities when TLS1.2 is
negotiated. It is the intention that it be backported to current and LTS
release lines with the default maximum TLS protocol reset to 'TLSv1.2'.
This will allow users of those lines to explicitly enable TLS1.3 if they
want.
API incompatibilities between TLS1.2 and TLS1.3 are:
- Renegotiation is not supported by TLS1.3 protocol, attempts to call
`.renegotiate()` will always fail.
- Compiling against a system OpenSSL lower than 1.1.1 is no longer
supported (OpenSSL-1.1.0 used to be supported with configure flags).
- Variations of `conn.write('data'); conn.destroy()` have undefined
behaviour according to the streams API. They may or may not send the
'data', and may or may not cause a ERR_STREAM_DESTROYED error to be
emitted. This has always been true, but conditions under which the write
suceeds is slightly but observably different when TLS1.3 is negotiated
vs when TLS1.2 or below is negotiated.
- If TLS1.3 is negotiated, and a server calls `conn.end()` in its
'secureConnection' listener without any data being written, the client
will not receive session tickets (no 'session' events will be emitted,
and `conn.getSession()` will never return a resumable session).
- The return value of `conn.getSession()` API may not return a resumable
session if called right after the handshake. The effect will be that
clients using the legacy `getSession()` API will resume sessions if
TLS1.2 is negotiated, but will do full handshakes if TLS1.3 is
negotiated. See https://github.com/nodejs/node/pull/25831 for more
information.
PR-URL: https://github.com/nodejs/node/pull/26209
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Rod Vagg <rod@vagg.org>
This commit removes the --diagnostic-report-verbose CLI option
and all associated logic. The flag is currently only used in one
place, and only reflects the settings at startup. Additionally,
Node tends to use the NODE_DEBUG mechanism for adding verbose
output.
PR-URL: https://github.com/nodejs/node/pull/26195
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Having an experimental feature behind a flag makes change
if we are expecting significant breaking changes to its API.
Since the Worker API has been essentially stable since
its initial introduction, and no noticeable doubt about
possibly not keeping the feature around has been voiced,
removing the flag and thereby reducing the barrier to experimentation,
and consequently receiving feedback on the implementation,
seems like a good idea.
PR-URL: https://github.com/nodejs/node/pull/25361
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Yuta Hiroto <hello@hiroppy.me>
Reviewed-By: Shingo Inoue <leko.noor@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Tiancheng "Timothy" Gu <timothygu99@gmail.com>
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
Reviewed-By: Masashi Hirano <shisama07@gmail.com>
Reviewed-By: Weijia Wang <starkwang@126.com>
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
This commit adds a --completion-bash option to node which can be
sourced to provide bash code completion for node options.
Usage:
$ node --completion-bash > node_bash_completion
$ source node_bash_completion
$ node --[tab]
PR-URL: https://github.com/nodejs/node/pull/20713
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Denys Otrishko <shishugi@gmail.com>
* Alphabetize the command line options and environment
variables in doc/api/cli.md for consistency and readability.
* Update doc/api/cli.md to include command line options
being printed in the `node.PrintHelp()` function in src/node.cc
but weren't otherwise documented in the cli spec. Options added
include:
--napi-modules
--v8-pool-size=num
--experimental-modules
--experimental-vm-modules
* ASCII sort the node man page command line options.
This change brings sort order consistency between the
cli options displayed in doc/node.1 and the cli options
enumerated in other areas of the project.
Also rearrange the language for `--use-bundled-ca`, `--use-openssl-ca`
to correspond with the order of the options as displayed.
* Update `node.PrintHelp()` function to return command line options
and environment variables sorted in ASCII order. Additionally,
add missing options as sourced from doc/api/cli.md. Options
added include `--`, `--help` and the `NODE_PRESERVE_SYMLINKS`
environment variable.
Also update the comments in the `node.PrintHelp()` method
to C++ style.
* Create tests to validate that the newly ASCII sorted
cli options in the `node.PrintHelp()` function are being
returned according to build configurations as expected.
PR-URL: https://github.com/nodejs/node/pull/19878
Refs: https://github.com/nodejs/node/issues/19814
Reviewed-By: Vse Mozhet Byt <vsemozhetbyt@gmail.com>
Reviewed-By: Khaidi Chu <i@2333.moe>
Reviewed-By: James M Snell <jasnell@gmail.com>
Like man(7), mdoc(7) is a macro package for marking up computer manuals.
The main difference is that mdoc is semantic rather than presentational,
providing authors with a full DSL to abstract page markup from low-level
Roff commands. By contrast, `man` is minimalist and leaves formatting to
the author, who is expected to have a working amount of Roff knowledge.
Therefore the use of `mdoc` for marking up Node's manpage is a decidedly
better choice than bare `man`. Less room is left for error and mandoc(1)
offers very robust error-checking and linting.
PR-URL: https://github.com/nodejs/node/pull/18559
Reviewed-By: Roman Reiss <me@silverwind.io>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
Bradley Farias