`uv_thread_setname()` sets the name of the current thread. Different
platforms define different limits on the max number of characters
a thread name can be: Linux, IBMi (16), macOS (64), Windows (32767),
and NetBSD (32), etc. `uv_thread_setname()` will truncate it in case
`name` is larger than the limit of the platform.
`uv_thread_getname()` gets the name of the thread specified by `tid`.
The thread name is copied into the buffer pointed to by `name`. The
`size` parameter specifies the size of the buffer pointed to by `name`.
The buffer should be large enough to hold the name of the thread plus
the trailing NUL, or it will be truncated to fit.
This commit introduces the `uv_thread_detach` for thread detaching,
allowing threads to be detached state on both UNIX and Windows platforms.
Signed-off-by: Juan José Arboleda <soyjuanarbol@gmail.com>
For any API that takes a buffer and size pointer, check both pointers
and the pointed-to size and return UV_EINVAL in case of error.
Example:
```
int uv_foo(char* buffer, size_t* size) {
if (buffer == NULL || size == NULL || *size == 0)
return UV_EINVAL;
...
}
```
In order to "peek" the necessary size for dynamic allocation, the
following pattern can be used:
```
char *buf;
char scratch[1];
size_t len = sizeof(scratch);
int r;
r = uv_foo(scratch, &len);
assert(r == UV_ENOBUFS);
buf = malloc(len);
r = uv_foo(buf, &len);
...
```
Requires updating the android builder, since the arm emulator is
deprecated and unavailable now. Switch to using a Github Action plugin
instead of a container, so that hopefully future updates will be
delivered via that channel instead.
Changed the idna test since printf returns EILSEQ for some byte
sequences in the format on Android in glibc. We don't fully understand
the cause, but we can avoid that by not asking it to reencode the bytes
in the current locale settings.
uv_wtf8_length_as_utf16() checks if codepoints are > 0xFFFF (to see if
it should be encoded as a surrogate pair), therefore uv_wtf8_to_utf16()
should too. Instead it checked > 0x1000. Harmonize the checks.
Fixes: https://github.com/nodejs/node/issues/55914
It happens due to the default firewall configuration on macOS >= 13.
Note: GH action runners have their firewall disabled, and yet, the test
fails all the same. Oh well...
Closes: https://github.com/libuv/libuv/issues/4263
It seemed incorrect to map a segfault to EACCES, since posix would typically
map this to EFAULT. The ERROR_BUFFER_OVERFLOW is literally "the filename is too
long", and is not typically an invalid parameter in posix.
Test originally added in #1060 to test the API, not the value.
After commit 18266a6969, it changed to return `ENOTDIR`, which makes it
consistent with other platforms but it also can be considered a breaking
change.
Delete the fs_event_error_reporting test. It fails in different ways,
most frequently on the TSan sanitizer buildbot, due to running out of
file descriptors when that is not expected, or vice versa, *not*
running out of file descriptors when that *is* expected.
The test creates a large number of event loops and expects to,
eventually, hit EMFILE but it sometimes hits it too early, and
sometimes not at all.
I don't think TSan is really responsible here, it just makes the
invalid assumption in the test itself more visible.
Fixes: https://github.com/libuv/libuv/issues/4368
Autobinding is a feature that lets the kernel pick a name for the
abstract socket, instead of userspace having to provide one.
Two bugs that this change exposed are also fixed:
1. strlen(sa.sun_path) can read past the end if the file path is exactly
sizeof(sa.sun_path) long (use memchr instead), and
2. don't return UV_ENOBUFS for abstract sockets when the buffer is
exactly large enough to hold the result; per commit e5f4b79809,
abstract socket names are not zero-terminated
MSVC does not actually support ubsan. There is a long-standing ticket
requesting this:
https://developercommunity.visualstudio.com/t/add-support-for-ubsan/840750
There are no known compilers that currently accept the
`/fsanitize=undefined` spelling. clang-cl accepts `-fsanitize...`,
same as regular clang.
Also passes no-sanitizer-recover so that tests actually fail.
Fix various ubsan-detected errors, including:
* win: fix req-inl.h ubsan failure
Don't use CONTAINING_RECORD macro from WinSDK, as it doesn't use the
right trick which avoids member access on null pointer.
Fixes:
```
src/win/req-inl.h:86:10: runtime error: member access within null pointer of type 'uv_req_t' (aka 'struct uv_req_s')
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior D:/a/libuv/libuv/src/win/req-inl.h:86:10
```
* test: fix ubsan failure on udp_ref3
Don't call functions through different function type.
Fixes:
```
src/win/udp.c:537:5: runtime error: call to function req_cb through pointer to incorrect function type 'void (*)(struct uv_udp_send_s *, int)'
test\test-ref.c:66: note: req_cb defined here
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior src/win/udp.c:537:5 in
```
* win: fix process-stdio.c ubsan failure
When accessing HANDLEs within the stdio buffer, use memcpy / memset in order to respect alignment.
Fixes:
```
src/win/process-stdio.c:197:5: runtime error: store to misaligned address 0x0230ee72d107 for type 'HANDLE' (aka 'void *'), which requires 8 byte alignment
0x0230ee72d107: note: pointer points here
00 00 cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd fd fd fd fd
^
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior src/win/process-stdio.c:197:5 in
```
* win: fix getaddrinfo.c ubsan failure
Reworks buffer alignment handling to respect requirements.
Fixes:
```
src/win/getaddrinfo.c:157:23: runtime error: member access within misaligned address 0x0290e4c6a17c for type 'struct addrinfo', which requires 8 byte alignment
0x0290e4c6a17c: note: pointer points here
00 00 00 00 cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd
^
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior src/win/getaddrinfo.c:157:23 in
```
* win: fix pipe.c ubsan failure
Changes "random" representation from pointer to number.
Fixes:
```
src/win/pipe.c:234:11: runtime error: applying non-zero offset to non-null pointer 0xffffffffffffffff produced null pointer
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior src/win/pipe.c:234:11 in
```
* unix: fix stream.c ubsan failure
Avoids performing pointer arithmetic on null pointer.
Fixes:
```
src/unix/stream.c:701:15: runtime error: applying zero offset to null pointer
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /Users/runner/work/libuv/libuv/src/unix/stream.c:701:15 in
```
If the corresponding environment variables are empty, the
uv_us_homedir() and uv_os_tmpdir() return garbage values. The reason
for this situation is the Windows API which doesn't return an error
even if the path is empty.
This PR fixes this problem by checking the return value of the API
call. If it is not an error and the length of the value is less than 3,
uv_us_homedir() and uv_os_tmpdir() will return UV_ENOENT.
Fixes: https://github.com/libuv/libuv/issues/2328
Under rare but benign circumstances (on XNU), incoming datagrams appear
to be dropped by the operating system after libuv has been notified of
their arrival but before libuv has had a chance to receive them.
Fixes: https://github.com/libuv/libuv/issues/4219
This commit changes the timestamps in the file, the ownership and the
group.
Fixes: https://github.com/libuv/libuv/issues/3125
Signed-off-by: Juan José Arboleda <soyjuanarbol@gmail.com>
Should hopefully make it easier to debug CI flakiness because
currently the test sometimes fails without a clear indication why.
Refs: https://github.com/libuv/libuv/issues/4106
Perform EPOLL_CTL_DEL immediately instead of going through
io_uring's submit queue, otherwise the file descriptor may
be closed by the time the kernel starts the operation.
Fixes: https://github.com/libuv/libuv/issues/4323
The kernel that ships with the new Ubuntu 22.04 CI image seems to have a
PIE slide that is bigger than the sanitizer runtimes can handle.
It makes ASan fail with thousands of "AddressSanitizer:DEADLYSIGNAL"
warnings, and MSan error with complaints about memory accesses outside
known ranges. Disabling address space layout randomization fixes both.
This commit also fixes a small bug in the platform_output test where
the cgroups v1 logic did not handle the "unlimited quota" special case
properly. Ubuntu 20.04 still uses cgroups v1.
uv_available_parallelism does not handle container cpu limit
set by systems like Docker or Kubernetes. This patch fixes
this limitation by comparing the amount of available cpus
returned by syscall with the quota of cpus available defined
in the cgroup.
Fixes: https://github.com/libuv/libuv/issues/4146
Add a process options flag to enable the optional behavior. Most users
are likely recommended to set this flag by default, but it was deemed
potentially breaking to set it by default in libuv.
Co-authored-by: Kyle Edwards <kyle.edwards@kitware.com>
The `\0` character has no special significance in abstract sockets, so
the addrlen field in both `bind()` and `connect()` should take that into
account.
Calling `uv_timer_start(h, cb, 0, 0)` from a timer callback resulted in
the timer running immediately because it was inserted at the front of
the timer heap.
If the callback did that every time, libuv would effectively busy-loop
in `uv__run_timers()` and never make forward progress.
Work around that by collecting all expired timers into a queue and only
running their callback afterwards.
Fixes: https://github.com/libuv/libuv/issues/4245
Co-authored-by: Ben Noordhuis <info@bnoordhuis.nl>
On IBM i this test fails asserting the write queue size.
The test expects the queue size to be greater than 0 but
the queue size is 0 on IBM i.
66160d6973/test/test-tcp-write-in-a-row.c (L75)
The test expects the write to get queued because the size of the data
is larger than the send and receive buffers.
66160d6973/test/test-tcp-write-in-a-row.c (L39-L40)
For some reason the request does not seem to get queued on IBM i.
The root cause of the issue will need further investigation.
Part of #4143
On Fedora's build system, the build environment runs on btrfs. This
revealed a bug in the test on i686 systems, where this comparison was
being performed as a comparison of two signed integers, but the
filesystem type of btrfs happens to use the higher-order bits, resulting
in it appearing as a negative value.
BTRFS_SUPER_MAGIC 0x9123683e
Signed-off-by: Stephen Gallagher <sgallagh@redhat.com>
Passing a socket name without a trailing nul byte to uv_pipe_bind2() or
(on Windows) uv_pipe_connect2() resulted in reading beyond the end of
the name buffer when copying or converting it.
Fix that by copying the socket name to temporary storage first and add
the trailing nul byte explicitly.
Add a check for embedded nul bytes in the socket name.
Fix a small memory leak in the Windows error path of uv_pipe_bind2().
There is no length at which this gets truncated on Windows. The
underlying file system will just not successfully connect to a longer
path (in WTF-16 characters), which will return an error asynchronously
with the existing API.
Refs: #4040
