When the user calls uv_async_send concurrently with uv_loop_close, we
try to prevent that data race from actually accessing undefined behavior
by setting the pending flag atomically with the busy flag. This was
proposed in the original PR, but we didn't have motivation to go with
this implementation until a user pointed out that it improves behavior
of the race window in more cases.
Previously, `uv__udp_io` would proceed to call `uv__udp_recvmsg` for
the `POLLERR` event even if the handle was just closed by the `POLLIN`
callback.
This commit adds a guard to verify the handle is still active before
processing the error queue. It also adds a regression test that
mimics this recursive closure behavior.
Fixes: https://github.com/libuv/libuv/issues/5030
Signed-off-by: Juan José Arboleda <soyjuanarbol@gmail.com>
Fix the casting of const char varaibles with const char returns from
functions, when the data being returned is not being modified. Includes
the part revert of "unix: fix compilation warnings with GCC 15"
This reverts commit 50ed2fd7bd.
Fix#4814 by adding const annotation when assigning string literal
"unknown" to `char*` pointer.
This eliminates compiler warnings when building with strict
const-correctness flags like `-Wwrite-strings`.
Add uv__get_rlimit_max_memory() helper that checks RLIMIT_AS and
RLIMIT_DATA resource limits across all Unix platforms. This helper
returns the minimum of these rlimits if set.
Update all Unix platform implementations of uv_get_constrained_memory()
to use this helper, ensuring consistent handling of resource limits:
- Linux: combine cgroup limits with rlimits
- z/OS: combine RLIMIT_MEMLIMIT with rlimits
- Other Unix platforms: use rlimits (previously returned 0)
This provides a more accurate view of available memory when processes
have rlimit constraints in addition to platform-specific limits.
Related: https://github.com/JuliaLang/julia/pull/51656
Co-Authored-By: Claude <noreply@anthropic.com>
some users of libuv rely on uv_exepath to be an actual path to a
program. unfortunately, the OpenBSD KERN_PROC_ARGV sysctl just returns
what is in argv[0], so if the program was executed by being looked up in
$PATH, uv_exepath would only return the basename and not an actual path.
to fix, this use the same approach as IBM i, OS/390 and AIX by searching
with uv__search_path. this is also the same approach the Zig language
has taken for the similar selfExePath function for OpenBSD.
the tests expect that uv_exepath still works after uv_set_process_title,
which on BSD is a call to setproctitle. the place setproctitle stores to
is the same place that KERN_PROC_ARGV reads from, so we need to stash
the original argv[0] in uv_setup_args to recover it later in uv_exepath.
It was reported that PTYs on Linux sometimes report POLLHUP, return a
partial read, but still return more data on the next read.
Libuv contains an optimization where it assumes a partial read after
POLLHUP means the next read can be skipped because it's going to fail
with EOF anyway. That assumption was thought to be always true but,
alas, it isn't.
The fact the optimization has been present for 13 years and this is the
first bug report about it, indicates how rare this particular condition
is, but of course we can't skim on correctness.
The reworked optimization only uses POLLHUP as an input signal when
POLLIN is not also set. That means we no longer have to track partial
reads because we're going to try and read anyway as long as POLLIN is
set. It seems to cause no measurable regressions on the test suite or
the (lightly tested) benchmarks.
Fixes: https://github.com/libuv/libuv/issues/4992
If uv_spawn() fails after uv__handle_init() has been called, the handle
remains in loop->handle_queue. This causes use-after-free if the handle
is stack-allocated or freed, and a subsequent loop operation like
uv_walk() accesses it.
This follows the same pattern as uv_tcp_init_ex() which explicitly
removes the handle from the queue on error.
Remove the microsecond truncation in uv__fs_to_timespec() function to enable
full nanosecond resolution support. The utimensat() system call already
supports nanosecond precision, so the artificial truncation to microseconds
is no longer necessary.
This allows file modification and access times to be set with full nanosecond
precision instead of being limited to microsecond resolution.
Fixes the TODO comment about removing the microsecond resolution limit.
The `flags` argument to `uv__udp_recvmsg_errqueue` was not initialized
in all code paths. Shuffle code around to make the control flow more
obvious (at the cost of a less legible diff.)
Also fixes an unused label warning when building on systems that aren't
Linux.
Introduced last month in commit 80a5e3ba0, "linux: add MSG_ERRQUEUE
ipv4/ipv6 udp support".
Add a stub function for no-ahafs builds. src/unix/core.c won't actually
call uv__ahafs_event but the linker still needs to see a symbol.
Like commit 87943b03 but for IBM i instead of AIX this time.
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).
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 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
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.
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
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.
