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>
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.
0x10FFFF is the valid max unicode character, so the check should be
inclusive.
This assert gets triggered because uv__wtf8_decode1 (used by
uv_wtf8_length_as_utf16) has the correct code_point <= 0x10FFFF check,
so the sequence is treated as valid and it will be passed into
uv_wtf8_to_utf16, where the incorrect assert gets triggered:
src/idna.c:397: uv_wtf8_to_utf16: Assertion `code_point < 0x10FFFF' failed.
Accomplish this by replacing `GetDiskFreeSpaceW()` with
`NtQueryVolumeInformationFile()` which allows us to represent blocks
larger than 2^32 - 1 via
`FILE_FS_FULL_SIZE_INFORMATION.TotalAllocationUnits`.
Expanded `fs_statfs` test to check that `uv_fs_statfs()` also works with
files, meaning https://github.com/libuv/libuv/issues/2683 remains fixed
without the need of https://github.com/libuv/libuv/pull/2695.
The test is multi-threaded and expects both threads to receive at least
some of the incoming connections but there isn't always true parallelism
under QEMU's user-mode emulator.
Single-core systems are also susceptible to that so also add a check
that we have at least two cores to run on.
As mentioned in the change for the udp_reuseport test from a few days
ago, the test is not perfect (there being > 1 core doesn't guarantee
we actually get to run on them) but it's better than nothing.
Fixes: https://github.com/libuv/libuv/issues/5003
The test is multi-threaded and expects both threads to receive at least
some of the incoming datagrams but there isn't always true parallelism
under QEMU's user-mode emulator.
Single-core systems are also susceptible to that so also add a check
that we have at least two cores to run on.
It's not perfect because a sufficiently dedicated test torturer could
probably concoct a containerized setup where the core count > 1 but the
available CPU slice is so small that the test effectively still runs
sequentially, but it's better than nothing.
Fixes: https://github.com/libuv/libuv/issues/4777
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
Check the length before doing the compare like we do a few lines below,
not the other way around. It's a false positive because the length is
capped well below the maximum object size but it's an easy fix.
Fixes the following warning:
test/test-poll-oob.c:94:19: warning: ‘strncmp’ specified bound
[18446744071562067968, 18446744073709551615] exceeds maximum
object size 9223372036854775807 [-Wstringop-overread]
The test previously assumed a default nice value of 0, but this can vary
depending on PAM configuration, /etc/security/limits.conf, or other environment
settings.
Fixes: https://github.com/libuv/libuv/issues/4898
Signed-off-by: Juan José Arboleda <soyjuanarbol@gmail.com>
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
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.
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.
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.
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
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>
Windows provides the `ENABLE_VIRTUAL_TERMINAL_INPUT` flag for TTY input
streams as a companion flag to `ENABLE_VIRTUAL_TERMINAL_PROCESSING`,
which libuv is already setting for TTY output streams.
Setting this flag lets the terminal emulator perform some of the
processing that libuv already currently does for input events,
but most notably enables receiving control sequences that are
otherwise entirely unavailable, e.g. for bracketed paste
(which the Node.js readline implementation added basic support for
in https://github.com/nodejs/node/commit/87af913b66eab78088acfd).
libuv currently already provides translations for key events to
control sequences, i.e. what this mode is intended to provide,
but libuv does not and cannot translate all such events.
Since the control sequences differ from the ones that Windows
has chosen to standardize on, and applications may not be expecting
this change, this is opt-in for now (but ideally will be the default
behavior starting in libuv v2.x, should that ever happen).
Another downside of this change is that not all shells reset
this mode when an application exits. For example, when running a
Node.js program with this flag enabled inside of PowerShell in
Windows terminal, if the application exits while in raw TTY input mode,
neither the shell nor the terminal emulator reset this flag, rendering
the input stream unusable.
While there's general awareness of the problem that console state is
global state rather than per-process (same as on UNIX platforms),
it seems that applications like PowerShell aren't expecting to need to
unset this flag on the input stream, only its output counterpart
(e.g. 4e7942135f/src/Microsoft.PowerShell.ConsoleHost/host/msh/ConsoleHost.cs (L1156)).
Hence, `uv_tty_reset_mode()` is extended to reset the terminal
to its original state if the new mode is being used.
Refs: 87af913b66
Refs: https://github.com/microsoft/terminal/issues/4954
Extend uv_fs_utime, uv_fs_futime and uv_fs_lutime to accept NAN and
INFINITY, with NAN meaning "don't touch the timestamp" and INFINITY
meaning "set to the current timestamp."
Ugly, but it avoids having to add uv_fs_utime2, etc.
UV_FS_UTIME_NOW and UV_FS_UTIME_OMIT constants have been added to make
it more palatable.
Fixes: https://github.com/libuv/libuv/issues/4665
