While unlikely that this fails (since it is implemented to call
`abort()` instead of actually return an error code, we would
theoretically leak this state. The process state init doesn't actually
have a cleanup, and just awkwardly relies on uv_signal_close being
unnecessary (which is likely true though).
There is a minor error about the return value of uv_cancel
for tasks that are already executing. All other parts of the
documentation correctly states that uv_cancel will fail.
_snwprintf_s takes its length argument in characters, not bytes.
Does not appear to be a security issue because the paths are not under
an attacker's control unless the system has been compromised beyond
salvation: requires a combination of being able to set the name of the
executable and/or changing %LOCALAPPDATA% or a registry key.
Refs: https://github.com/libuv/libuv/security/advisories/GHSA-jjrx-vr7q-7732
The static initial table reserved space for MxN elements but only used
every Nth element. Removing the excess elements shrinks the table 16x.
I added search/insertion/deletion time logging while here to ensure no
performance regressions.
Fixes: https://github.com/libuv/libuv/issues/4823
Rationale for changing it to an enum:
- frees up some bits that can be used for other things
- is potentially faster (direct vs. indirect call)
- is potentially more secure (makes UAF or overruns harder to exploit,
no arbitrary function pointer to clobber)
Fixes: https://github.com/libuv/libuv/issues/4842
The AArch64 YIELD instruction affects processors that support
symmetric multithreading, while on other implementations (which
are the majority on the market) it is equivalent to NOP, thus
failing to achieve the desired delay effect inside uv__async_spin().
Instead, use the ISB instruction, following one of Arm's
recommendations [1].
[1] https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/multi-threaded-applications-arm
Signed-off-by: Anton Kirilov <anton.kirilov@arm.com>
This fixes the test suite in environments where `/tmp` is not writable
or does not allow the use of Unix sockets, and matches the use of
relative paths elsewhere in the tests.
This apparently manifests when one passes `--cpu=.5` to docker because
then /sys/fs/cgroup/cpu.max looks like `50000 100000`, and 50000 divided
by 100000 is zero when using integer math.
Return 1 in that case, indicating there is at least one CPU available.
Returning 0 makes no sense because there is always at least one CPU
available, otherwise the program wouldn't be running.
Fixes: https://github.com/nodejs/node/issues/59200
Fix a logic bug in the fallback code for platforms that don't have a
sendmmsg-like system call. It only sent at most one packet, even when
there were more available, and that was observable through a failing
test on such systems.
Fixes: https://github.com/libuv/libuv/issues/4848
Wine has a bug (https://bugs.winehq.org/show_bug.cgi?id=50771) where
FILE_WRITE_ATTRIBUTES will cause CreateFile to fail if the file is
read-only. The recommended work around is to instead use
FILE_DISPOSITION_IGNORE_READONLY_ATTRIBUTE, which we do as of #4318.
However, we were still using FILE_WRITE_ATTRIBUTES to create the
initial handle, despite this no longer being required, except for
the fallback path. As a result, libuv is still broken under wine,
even on master. Fix this by removing the `FILE_WRITE_ATTRIBUTES`
from the initial CreateFile call and re-opening the handle in the
fallback path if necessary. Note that we still have the same issue
in fs_chmod and I've requested some guidance from wine on what
to do about this, but this should at least fix unlink.
Refs: https://github.com/JuliaLang/julia/issues/58980
I was testing a static analyzer on libuv's code, and it could not
understand the use of a constant variable in the condition as an assert
branch. This simplifies the code for easier static analysis. I also
removed the explicit casts, relying instead on C's casting rules to
catch some misuse.
Starting a new read after uv_read_cb returns causes memory corruption on
the OVERLAPPED read_req if uv_read_stop+uv_read_start was called during
the callback after the latest refactoring. This apparently also forces
the kernel to deadlock us, since it apparently cannot cancel the second
read while the first one is pending (reads apparently are not permitted
to finish out of order). Avoid that simply by not issuing another read
(set more=0) if there is already a read pending (from uv_read_start).
There are probably better things we could do here (such as bring back
`uv_active_tcp_streams_threshold`), but the current `alloc_cb` design
may not currently permit that without making breaking changes. We could
also detect in `uv_read_start` that we are inside of of the `read_cb`
for that stream, and defer the actual zero-read until the read_cb
returns, but that would likely be a larger change.
Fix#4738
Large-ish functions with many call sites in different translation units
should not be `static inline`, that just results in lots of code
duplication which the linker may or may not deduplicate. When it does,
the linker has to do extra work; when it doesn't, binaries get bigger.
Refs: https://github.com/libuv/libuv/issues/4819
Commit 7fb43d3c from August 2012 moved uv__atomic_exchange_set from
async.c into a header file but in all those years, nothing except
async.c has ever used it. Move the function back again and remove
the header file.
I removed the superfluous uses of inline/INLINE but this is otherwise
a non-functional change.
Refs: https://github.com/libuv/libuv/issues/4819
uv_set_process_title loads and unloads a bunch of dynamic libraries,
and that's quite slow and prone to time out when running concurrently
under AddressSanitizer.
