Open
Conversation
The firewall was suspected to be the culprit, but the test intermittently fails in the CI, not locally.
Fixes a deprecation warning with new cmake versions. Changing the minimum from 3.9 to 3.10 should be safe because there isn't even a non-EoL'd distro left that ships 3.10, let alone 3.9. Fixes: #4603
Establishes a user event for kqueue to eliminate the overhead of the pipe and the system call read(2) per wakeup event. Relands commit 2713454 using VSCode merge, since it shows the conflict is just on the order of #ifdef calls. Co-authored-by: Andy Pan <panjf2000@gmail.com>
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: nodejs/node#55914
Merge kevent calls along with the improvement of code simplicity. Signed-off-by: Andy Pan <i@andypan.me>
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.
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);
...
```
Fixes: #3947 Signed-off-by: Juan José Arboleda <soyjuanarbol@gmail.com>
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>
`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.
Upgrade GHA image to Ubuntu 24.04 and use the distro-provided qemu. It should not be necessary anymore to install qemu from .deb because the stock qemu is new enough in 24.04.
Libuv looks for "Processor" in /proc/cpuinfo but it's been reported that on at least some Raspberry Pi models, it's called "model name". Look for both. Fixes: nodejs/node#56105
io_uring support was default-disabled because of numerous kernel bugs but those are all in the sqpoll (file i/o) parts of io_uring. Batching of epoll_ctl calls through io_uring works fine, is a nice optimization, and is therefore unconditionally enabled again. The UV_USE_IO_URING environment variable now only affects sqpoll, and only when the UV_LOOP_ENABLE_IO_URING_SQPOLL event loop flag is set. Fixes: #4616
It was introduced in Vista, so we can assume it's always there now.
The OG MinGW has been dead for years, MinGW-w64 has taken its place.
The documentation overwhelmingly uses :c:func:`foo`. Rewrite the few places that write it as c:func:`foo()` without the parentheses.
And fix it by calling uv_free_cpu_info so we don't repeat repeat ourselves.
Reserve one byte for the NUL terminator when passing the buffer size to uv_utf16_to_wtf8() in the TTY line-read path. Without this, when all input characters encode to exactly 3 UTF-8 bytes (e.g. CJK) and the buffer size is divisible by 3, the NUL terminator is written one byte past the allocated buffer. The other two call sites in src/win/util.c already subtract 1 before calling uv_utf16_to_wtf8(). This aligns tty.c with that convention. Fixes commit f388908 ("win,tty: convert line-read UTF-16 to WTF-8") from October 2023. Refs: https://github.com/libuv/libuv/security/advisories/GHSA-4prr-4742-3ccf
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.
Looks like this was simply missed in #3183 because it was a bit outside the review context window.
Port 143da93 to Windows: replace the 250 ms settle delay with a pipe- based synchronization mechanism. The parent creates a pipe, passes the write-end handle to the helper via UV_TEST_RUNNER_FD, then blocks on ReadFile() until the helper calls notify_parent_process() and closes its copy of the handle. Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
This avoids a blocking syscall (essentially a write)–and thus potential deadlock–in the asynchronous IO path.
This is not precisely a strict rule, but this syntax is reinforced in many large C projects like the Linux kernel and cURL. Signed-off-by: Juan José Arboleda <soyjuanarbol@gmail.com>
Replaces `[image]` tags in libuv manual page with a textual representation of the graphical image. In addition added alternative-text for graphical deliverables. Fixes: #4708
Fixed race conditions and memory safety issues in the progress example by using C11 atomic operations for proper thread synchronization. Changes: - Changed percentage from double to _Atomic double - Use atomic_store_explicit() with memory_order_release when writing - Use atomic_load_explicit() with memory_order_acquire when reading - Removed unsafe pointer passing via async.data This ensures proper memory synchronization between the worker thread and async callback, preventing data races and dangling pointer issues. Fixes #4386 Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
* win: initialize INIT_ONCE field with dedicated initializer Fixes: abc9767 ("win: simplify uv_once implementation") * win: indendation fixes * win: squash some compiler warnings
- Replace dead developer.ibm.com AIX article with current IBM Docs URL - Update IBM Knowledge Centre z/OS URL to new ibm.com/docs location - Update docs.microsoft.com links to learn.microsoft.com - Update curl.haxx.se links to curl.se - Update c-ares.haxx.se to c-ares.org - Update tools.ietf.org RFC link to datatracker.ietf.org - Update www.tldp.org links to tldp.org (drop www) - Update www.nodejs.org and www.rust-lang.org (drop www) - Upgrade http://docs.libuv.org links to https - Replace dead kkaefer.com link with GitHub Pages + YouTube video Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
The document doesn't reference libev anywhere else so it's rather incongruous to mention it here. Also add a comma to make the sentence flow better.
Previously, the user might unknowingly close a uv_process_t before doing waitpid on the zombie, leaving it forever undead. Track the state of the child, so that the application wrapper can avoid this by calling uv_process_kill and checking for UV_ESRCH error.
The fcntl cannot fail at this point but let's check the return code anyway, just in case. Fixes: #5080
The function is only used on BSDs. Introduced in commit 919b92d ("unix: support long path names in pipe.c") from a few days ago.
The documentation already stated that the receive buffer should be a multiple of 64 KiB when the UV_UDP_RECVMMSG is used, but make that more prominent in the documentation and enforce it in the code. Refs: https://github.com/libuv/libuv/security/advisories/GHSA-r846-fxvr-f3rx
Because libuv truncates the result of every call to INT32_MAX, it needs to internally limit operations to INT32_MAX to be safe to use libuv. This isn't an API change, since these operations weren't guaranteed to work, and in fact usually failed in bizare ways already. This is very long in coming, since we've had a lot of compiler warnings about this and several PRs to fix this open for a decade, but the main consumers that usually fix things didn't care (nodejs is 32-bit and julia patched this downstream more than a decade ago, though it did run into this again recently by mistake with sendfile). Replaces #1501 Fixes #3360
Copy the optimization from tcp/udp stack: when read/writes don't require IOCP to complete, put them directly right into the pending queue, so they can be processed without a full loop through IOCP each time to drain them asynchronously.
Like #4810, but for all socket calls.
Remove the conditionals so that posix_spawn will be used whenever possible, and not only on Apple. Tests specifically if posix_spawn works before using it: it is broken on QEMU with glibc, for example, since fork/clone is broken there.
Fixes a -Wincompatible-pointer-types error on Windows, since uv_os_fd_t is not int but HANDLE.
The project has been getting a flood of private vulnerability reports, most of which are invalid, and a few of which should have just been normal bugs. This has essentially been a DoS attack on maintainer time, since we're unable to change them into normal bugs after assessment. We now have a libuv-security@googlegroups.com list instead to help redirect those seeking CVE fame. The hope is to redirect most people to actually use the issue list as it has always been intended to be used.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )