This patch refactors the DNS default resolver code to make it
easier to be included in a snapshot:
- The code specific for the callback-based DNS resolver are not
in a separate module to make the dependency clearer (it's not
actually needed if the user only ever loads `dns/promises`)
- The common part of the callback-based resolver and the promise-
based resolver is now ResolverBase. The other two user-facing
resolvers are now subclasses of ResolverBase. The default
Resolver is constructed with just ResolverBase. This would
be fine as the default resolver is never actually exposed
to the user-land and it has been working using duck-typing anyway.
- Move the construction of Resolver subclasses into a common
method `createResolverClass()` to reduce code duplication.
The two subclasses now also share the same base constructor.
This would make it possible for them to also share code
for snapshot support later.
- `--dns-result-order` is now queried and refreshed during
pre-execution. To avoid loading the cares_wrap binding unnecessarily
the loading of the binding is also made lazy.
PR-URL: https://github.com/nodejs/node/pull/44541
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Zeyu "Alex" Yang <himself65@outlook.com>
Reviewed-By: Minwoo Jung <nodecorelab@gmail.com>
OpenSSL internally represents the output length and the iteration count
as signed integers, which is why node's C++ implementation expects these
arguments to fit into signed integers as well. The JavaScript validation
logic, however, only requires the arguments to be unsigned 32-bit
integers, which is a superset of non-negative (signed) 32-bit integers.
Change the JavaScript validation to match the expectation within C++.
Fixes: https://github.com/nodejs/node/issues/44570
PR-URL: https://github.com/nodejs/node/pull/44575
Reviewed-By: Filip Skokan <panva.ip@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Mohammed Keyvanzadeh <mohammadkeyvanzade94@gmail.com>
On Windows it might take too long for the parent to start the
communication with a child process, so by the time the parent
starts its own timer, the child process might have already
completed running, and the parent in those tests won't have a
chance to terminate these child processes after the timeout.
To address this issue, raise the time for which the child is
supposed to run to make sure that the parent starts
its own timer before the child terminates in the tests.
Also, split the test into smaller ones to reduce the overhead.
PR-URL: https://github.com/nodejs/node/pull/44390
Refs: https://github.com/nodejs/reliability/issues/356
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Stephen Belanger <admin@stephenbelanger.com>
This does not fix occurrences in test/parallel/test-dns-* because those
tests contain unrelated pre-existing bugs that would cause the tests to
fail with this fix. This unrelated bug in those tests should be fixed
separately before the use of mustNotCall() can be fixed in those files.
PR-URL: https://github.com/nodejs/node/pull/44022
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Juan José Arboleda <soyjuanarbol@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Context's default IsCodeGenerationFromStringsAllowed value can be
changed by v8 flag `--disallow-code-generation-from-strings`. Restore
the value at runtime when delegating the code generation validation to
`node::ModifyCodeGenerationFromStrings`.
The context's settings are serialized in the snapshot. Reset the setting
values to its default values before the serialization so that it can be
correctly re-initialized after deserialization at runtime.
PR-URL: https://github.com/nodejs/node/pull/44324
Fixes: https://github.com/nodejs/node/issues/44287
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
sequential/test-child-process-execsync and
parallel/test-child-process-spawnsync-timeout are both flaky
on azure Windows machines, where it may take longer for Node.js
to launch and receive output from child processes. These tests
work by spawning a child processes that is supposed to sleep
for a long time, but the option is configured so that Node.js
would terminate them early when a shorter timeout is reached.
Then the tests assert that the time taken for the whole thing
is shorter than the specified sleep time (meaning the process
don't actually get to sleep for that long). To make the tests
less brittle on azure Windows, this patch raises the sleep
times in those tests on Windows platform, so that the overhead
can be taken into account there.
PR-URL: https://github.com/nodejs/node/pull/44375
Refs: https://github.com/nodejs/build/issues/3014
Reviewed-By: Moshe Atlow <moshe@atlow.co.il>
Reviewed-By: Nitzan Uziely <linkgoron@gmail.com>
The THROW_ERR_* functions interpret the first argument as a printf-like
format string, which is problematic when it contains unsanitized user
input. This typically happens when a printf-like function is used to
produce the error message, which is then passed to a THROW_ERR_*
function, which again interprets the error message as a format string.
Fix such occurrences by properly formatting error messages using static
format strings only, and in a single step.
PR-URL: https://github.com/nodejs/node/pull/44314
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Darshan Sen <raisinten@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Zeyu "Alex" Yang <himself65@outlook.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Add WebPerf API `performance.setResourceTimingBufferSize` and event
`'resourcetimingbufferfull'` support.
The resource timing entries are added to the global performance
timeline buffer automatically when using fetch. If users are not
proactively cleaning these events, it can grow without limit. Apply
the https://www.w3.org/TR/timing-entrytypes-registry/ default
resource timing buffer max size so that the buffer can be limited
to not grow indefinitely.
PR-URL: https://github.com/nodejs/node/pull/44220
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
It's difficult for V8 to handle Error.stackTraceLimit in the snapshot,
so delete it from the Error constructor if it's present before
snapshot serialization, and re-install it after deserialization.
In addition try not to touch it from our internals during snapshot
building in the first place by updating
isErrorStackTraceLimitWritable().
PR-URL: https://github.com/nodejs/node/pull/44203
Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Joyee Cheung