PR-URL: https://github.com/libuv/libuv/pull/2895
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
This was part of commit c70dd705 ("unix: use relaxed loads/stores for
feature checks") and was reviewed as such but I accidentally dropped
it in the rebase before the final merge.
Fixes: https://github.com/libuv/libuv/issues/2884
PR-URL: https://github.com/libuv/libuv/pull/2886
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Jameson Nash <vtjnash@gmail.com>
This issue manifested on `connected` udp sockets trying to send
datagrams to a non-existent server and returning `ECONNREFUSED` because
an ICMP error was received before the actual sending was performed.
PR-URL: https://github.com/libuv/libuv/pull/2899
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
It was reported that mach_absolute_time() can jump backward in time when
the machine is suspended. Use mach_continuous_time() when available to
work around that (macOS 10.12 and up.)
Fixes: https://github.com/libuv/libuv/issues/2891
PR-URL: https://github.com/libuv/libuv/pull/2894
Reviewed-By: Phil Willoughby <philwill@fb.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
`__atomic_load_n()` and friends were added in gcc 4.7.0 but we still
have some centos6 machines with a vintage gcc 4.4.7 from 2012 in the
CI matrix.
PR-URL: https://github.com/libuv/libuv/pull/2888
Refs: https://github.com/libuv/libuv/pull/2886
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Make ThreadSanitizer stop complaining about the static variables that
libuv uses to record the presence (or lack) of system calls and other
kernel features.
Fixes: https://github.com/libuv/libuv/issues/2884
PR-URL: https://github.com/libuv/libuv/pull/2886
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Jameson Nash <vtjnash@gmail.com>
The variable uv__read_console_status is left as IN_PROGRESS when the
operation is canceled ahead of time by the main thread requesting a
trap (race condition?).
This confuses the next call to uv__cancel_read_console(...) causing
a deadlock due to a semaphore acquisition that is never released by
the reading thread.
Setting the status variable back to COMPLETE or NOT_STARTED fixes
the issue.
Ref: https://github.com/nodejs/node/issues/32999
PR-URL: https://github.com/libuv/libuv/pull/2882
Reviewed-By: Bartosz Sosnowski <bartosz@janeasystems.com>
It was reported that uv_loadavg() reports the wrong values inside an
lxc container.
Libuv calls sysinfo(2) but that isn't intercepted by lxc. /proc/loadavg
however is because /proc is a FUSE fs inside the container.
This commit makes libuv try /proc/loadavg first and fall back to
sysinfo(2) in case /proc isn't mounted.
This commit is very similar to commit 3a1be725 ("linux: read free/total
memory from /proc/meminfo") from April 2019.
Fixes: https://github.com/nodejs/node/issues/33791
PR-URL: https://github.com/libuv/libuv/pull/2876
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Move common logic into a separate function that will be reused in a
follow-up commit. This commit also adds a minor correctness fix in
that the `read(2)` system call is now retried on `EINTR`.
PR-URL: https://github.com/libuv/libuv/pull/2876
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
It was reported that `getrlimit(RLIMIT_STACK)` fails on some aarch64
systems due to a glibc bug, where the getrlimit() system call wrapper
invokes the wrong system call.
Libuv could work around that by issuing a `prlimit(2)` system call
instead but since it can't assume that said system call is available
(it was added in Linux 2.6.36, libuv's baseline is 2.6.32) it seems
easier to just use the default 2M stack size when the call fails.
Fixes: https://github.com/nodejs/node/issues/33244
Refs: https://bugzilla.redhat.com/show_bug.cgi?id=1813089
PR-URL: https://github.com/libuv/libuv/pull/2848
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
Libuv was copying `sizeof(struct sockaddr_storage)` bytes from source to
destination but the source was only `sizeof(struct sockaddr_in6)` bytes
big, or approximately 128 vs. 16 bytes.
Fixes: https://github.com/libuv/libuv/issues/2840
PR-URL: https://github.com/libuv/libuv/pull/2841
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Replace two biggish `struct sockaddr_storage` instances with a union
of `struct sockaddr_in` and `struct sockaddr_in6`, the latter being
the largest that function supports.
PR-URL: https://github.com/libuv/libuv/pull/2841
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
`uv_signal_init()` leads to the allocation of an IO watcher,
so if the loop initialization fails at a later point,
the `loop->watchers` list needs to be released.
PR-URL: https://github.com/libuv/libuv/pull/2837
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Exposes the original system error of the filesystem syscalls. Adds a new
uv_fs_get_system_error which returns orignal errno on Linux or
GetLastError on Windows.
Ref: https://github.com/libuv/libuv/issues/2348
PR-URL: https://github.com/libuv/libuv/pull/2810
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
I was getting some weird results when copying a 5GB file on Alpine
Linux on Raspberry Pi. Out of the 5GB only 1.1GB would get copied and
the process would finish without an error. After some digging I found
out that there's a problem that some data types have smaller number of
bytes on Alpine Linux on Raspberry Pi than on other platforms
apparently.
When getting the size of the file in bytes, stat holds the size in
off_t data type, like this:
struct stat {
...
off_t st_size; /* total size, in bytes */
...
};
In my case, off_t has 8 bytes which is enough to hold a value up to
some exabytes. The problem is that it gets assigned to bytes_to_send
variable, which is size_t. In my case, size_t is only 4 bytes, which
is only good for about 4GB. If the file is any larger, there's an
overflow when assigning it from stat to bytes_to_send. That's easy
to fix, I just changed the data type of bytes_to_send to off_t.
However there's more.
The other 2 variables - in_offset and bytes_written also have to be
able to hold the size of the entire file, therefore it makes sense to
change them to off_t as well.
The last problem is that bytes_to_send is passed down to
uv_fs_sendfile() which converts it to size_t again. I could go and
change the types everywhere across the whole codebase to off_t but
that could break other things, so it seams a bit too much. A much
better solution is to have a proxy variable bytes_chunk that is
size_t type and copy as much bytes as possible at a time that can
fit into size_t. That way it will work the same as before on other
platforms, where size_t is more than 4 bytes.
PR-URL: https://github.com/libuv/libuv/pull/2758
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Commit 3d713663 ("freebsd,linux: add recvmmsg() + sendmmsg() udp
implementation") forgot to zero some of the members of the msghdr
struct. It seems to work by accident, not by design.
PR-URL: https://github.com/libuv/libuv/pull/2819
Refs: https://github.com/libuv/libuv/pull/2818
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
The Windows documentation states these should not be possible
but several people have reported that they do in fact happen.
Try with a smallish stack-allocated buffer first and switch to
a heap-allocated buffer if the first one is too small.
Fixes: https://github.com/libuv/libuv/issues/2587
PR-URL: https://github.com/libuv/libuv/pull/2589
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Since Windows 10 1607 some WinApi functions no longer have a MAX_PATH
limit on the filenames length. This removes this hard-coded path length
limit from various places in libuv, switching to dynamically allocating
string buffers.
Fixes: https://github.com/libuv/libuv/issues/2331
PR-URL: https://github.com/libuv/libuv/pull/2788
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Commit 5736658b ("udp: add flag to enable recvmmsg(2) explicitly") added
the flag but didn't update the validation logic in src/win/udp.c.
This commit moves the validation logic to src/uv-common.c. The flag is
now accepted as a no-op on Windows.
Fixes: https://github.com/libuv/libuv/issues/2806
PR-URL: https://github.com/libuv/libuv/pull/2809
Reviewed-By: Bartosz Sosnowski <bartosz@janeasystems.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Libuv already works without that API since commit 153ea114ff but still
had it as a hard requirement in the import table. This code uses the
`pGetQueuedCompletionStatusEx` function pointer instead, hence it also
works on systems that don't export `GetQueuedCompletionStatusEx`.
This simple fix improves compatibility of libuv with ReactOS and
Windows XP (latter using Vista+ compatibility libraries like
https://github.com/MyTDT-Mysoft/DllCompat)
PR-URL: https://github.com/libuv/libuv/pull/2800
Reviewed-By: Bartosz Sosnowski <bartosz@janeasystems.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Make it possible to explicitly tell libuv to release any resources
it's still holding onto (memory, threads, file descriptors, etc.)
Before this commit, cleanup was performed in various destructors.
This commit centralizes the cleanup logic, enabling the addition of
`uv_library_shutdown()`, but maintains the current observable behavior
of cleaning up when libuv is unloaded by means of `dlclose(3)`.
Fixes: https://github.com/libuv/libuv/issues/2763
PR-URL: https://github.com/libuv/libuv/pull/2764
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
On Linux, cpu_times have been calculated differently to all other
platforms for a while. Other platforms (FreeBSD, Mac, Windows) are all
in milliseconds, but Linux has been returning values ten times larger.
libuv has not previously documented what unit cpu_times uses, even
though NodeJS did - as milliseconds.
Here we're both documenting that the cpu_times are indeed in
milliseconds, and fixing the inconsistency on Linux.
Fixes: https://github.com/libuv/libuv/issues/2773
PR-URL: https://github.com/libuv/libuv/pull/2796
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
`timer_less_than()` function is basically a comparator function
that returns true or false. In the end of the function we were
checking for the comparison of id, but the later if is redundant
as we are anyways in the end are returning `0`. That extra check
can thus be safely removed.
PR-URL: https://github.com/libuv/libuv/pull/2785
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
`required_vars_value_len` has a fixed number of elements. There is no
need to use alloca() to allocate it.
Refs: https://github.com/libuv/libuv/pull/2781
PR-URL: https://github.com/libuv/libuv/pull/2783
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
In commit 2475296c (build: make code compilable for iOS on Xcode,
2020-01-18, v1.35.0~47) we added a `defined(TARGET_OS_IPHONE)`
preprocessor condition, but `TARGET_OS_IPHONE` is always defined on
Apple to either 0 or 1. On 32-bit macOS architectures this
leads to an undefined symbol reference to `_close$NOCANCEL`.
Fix the preprocessor condition to use just `TARGET_OS_IPHONE`.
Refs: https://github.com/libuv/libuv/pull/2639
PR-URL: https://github.com/libuv/libuv/pull/2776
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Check the pointer to the allocated memory, not the pointer to the
pointer of the allocated memory. Previously, a failed allocation of
*envitems would lead to a NULL pointer dereference.
PR-URL: https://github.com/libuv/libuv/pull/2778
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Bartosz Sosnowski <bartosz@janeasystems.com>
Check the pointer to the allocated memory, not the pointer to the
pointer of the allocated memory. Previously, a failed allocation of
*envitems would lead to a NULL pointer dereference.
PR-URL: https://github.com/libuv/libuv/pull/2778
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Bartosz Sosnowski <bartosz@janeasystems.com>
Emits yield instruction in ARM mode (mainly needs to pass -march=...).
PR-URL: https://github.com/libuv/libuv/pull/2751
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
PR-URL: https://github.com/libuv/libuv/pull/2767
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: David Carlier <devnexen@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
At least two people have reported that `LoadLibrary("advapi32.dll")`
fails in some configurations.
Libuv already links against advapi32.dll so let's sidestep the issue
by linking to `RtlGenRandom()` directly instead of looking it up at
runtime.
Fixes: https://github.com/libuv/libuv/issues/2759
PR-URL: https://github.com/libuv/libuv/pull/2762
Reviewed-By: Bartosz Sosnowski <bartosz@janeasystems.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Jameson Nash <vtjnash@gmail.com>
In e14c56b, support was added to implement true isatty() support when
running in the IBM i PASE environment, but it did not handle EBADF
properly. This commit fixes the EBADF handling, but because the
handling was a bit more complicated than previously, it was moved to a
separate isatty function to keep the mainline code simpler.
This also documents why we can't just use isatty on PASE a little more
completely.
PR-URL: https://github.com/libuv/libuv/pull/2753
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
In the emulated nanosleep() function on z/OS an EAGAIN error from
BPX1CTW/BPX4CTW indicates that the timeout has expired. In that
case return 0 and not -1.
PR-URL: https://github.com/libuv/libuv/pull/2737
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
z/OS doesn't support POSIX semaphores. On Release builds the code
paths that reference POSIX semaphore functions (e.g. sem_init())
are optimized away so linking succeeds but on a non-Release build
the references to the unavailable functions result in unresolved
symbol errors.
Stub the unavailable POSIX semaphore functions on z/OS as so the
code can link on non-Release builds.
PR-URL: https://github.com/libuv/libuv/pull/2737
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
When recvmmsg support was added it returned the datagrams in reverse
received order, which may impact some applications.
To restore the previous behavior, we call recv_cb one last time with
nread == 0 and addr == NULL so applications can free the buffer.
PR-URL: https://github.com/libuv/libuv/pull/2736
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Modeled after FreeBSD's `reallocf(3)`: a version of `realloc(3)` that
frees the memory when reallocation fails, simplifying error handling in
many cases.
PR-URL: https://github.com/libuv/libuv/pull/2735
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
PR-URL: https://github.com/libuv/libuv/pull/2013
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Signed-off-by: Irek Fakhrutdinov <ifakhrutdinov@rocketsoftware.com>
