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.
Distinguish between errors and "the console title is the empty string"
when calling GetConsoleTitle. Both are signified by a return value of
zero.
No test because I couldn't think of a succinct way to programmatically
create a new console window with an empty title.
Fixes: https://github.com/nodejs/node/issues/58695
Implement `uv_tcp_keepalive_ex` function that extends
`uv_tcp_keepalive` to support `TCP_KEEPINTVL` and `TCP_KEEPCN`
socket options in addition to TCP_KEEPIDLE.
The documentation is referring to an internal name -
UV_LOOP_ENABLE_IO_URING_SQPOLL - in several places. Fix this by using
the public UV_LOOP_USE_IO_URING_SQPOLL name instead.
Handle out-of-memory conditions in uv_loop_init better, albeit still
not perfect: bubble up the error instead of aborting.
Also fixes a file descriptor leak on Linux (and likely other platforms)
that the new test caught; the backend epoll fd was being leaked in the
error path.
Fixes: https://github.com/libuv/libuv/issues/4755
I changed the default stack size in commit 73b0c1f94 from October 2022
and although I added a versionchanged note, I didn't update the blurb
a few lines below.
It wasn't accurate before that change either though, because even with
musl libc's ~80kb thread stacks, 128 threads works out to 10 MB.
Refs: https://github.com/nodejs/node/issues/57911
Haiku has parallel types to stdint.h, and their APIs use these
types. In the Haiku-specific haiku.h file, it is passing an
address of a uint32_t to get_cpu_topology_info(), that expects
the other uint32:
648fa5897c/src/system/libroot/os/system_info.cpp (L187)
You get an "incompatible-pointer-types" warning in gcc if the
warnings are turned up. But if you pass the pointer to Haiku's
notion of uint32, then the warning goes away.
On some platforms (like GNU/Hurd), `getsockname` returns an empty
string for sockets in the UNIX domain. However, we do have stored the
path info in `pipe_fname` of `uv_pipe_t`, so we can try with it
if `getsockname` returns an empty string.
Use fchmod() on platforms that support it on UNIX sockets. Only fall
back to chmod() on platforms that don't (macOS and the BSDs.)
Remove the stat + chmod dance from the fallback and just call chmod
directly, because that's another source of TOCTOU issues.
Fixes: https://github.com/libuv/libuv/issues/2040
Documentation on Linux explains that nul bytes have no
special significance in abstract namespace socket names.
Avoid precluding such addresses.
Signed-off-by: Itay Bookstein <ibookstein@gmail.com>
After 14 years that should be fairly safe, right? Right!?
Not safe enough for Windows Server 2016 apparently; there are build
errors coming from system headers. The GHA images are slated for removal
in a month anyway so upgrade them to Windows Server 2025.
Fixes: https://github.com/libuv/libuv/issues/4742
