The read callback failed to handle the `nread == 0` case, which is rare
to non-existent on the systems we test on but apparently happens often
enough on Solaris on SPARC to draw attention.
Fixes#3469.
Take into account that the data may not be already available in the
socket causing the `recvmsg()` / `recvmmsg()` calls to return `EAGAIN`
or `EWOULDBLOCK`.
Fixes: https://github.com/libuv/libuv/issues/3479
I created `uv__backend_timeout` to be used internally for this reason,
then forgot to use it, resulting in flaky tests and excessive trips
around the uv_run loop.
Fix#3472
- Fixes the declaration of the benchmark in benchmark-list.h (it was not
previously runnable at all)
- Fixes the benchmark itself hanging infinitely because the data was
being dropped via ICMP Destination Unreachable errors (meaning nread
was always zero in pinger_read_cb)
+ The data getting lost was fixed by binding the udp socket
- Properly checks for UV_UDP_MMSG_CHUNK, just as an example of what
should generally be done (buf_free is actually a no-op as the buf is
allocated on the stack)
If we try to use uv_fs_rmdir on a read-only directory on Windows, it
internally calls _wrmdir, which sets _doserrno to ERROR_ACCESS_DENIED
and errno to EACCES. However, ERROR_ACCESS_DENIED is mapped to
UV_EPERM, so I believe it should be remapped to UV_EACCES.
Currently `LoadLibraryA` call first attempts to load the given DLL from
the application working directory before loading it from the system DLL
path. This may pose a security risk if an attacker is able to place a
malicious DLL into the application working directory as that DLL will
be loaded instead of the system DLL. This is especially dangerous if
the application is running with elevated privileges.
This changes the DLL loading to use `LoadLibraryExA` method with
`LOAD_LIBRARY_SEARCH_SYSTEM32` flag which restricts the DLL load
path to system DLL path, ignoring any DLLs in the application working
directory.
Reverts 442aa1f469, since this is an
improved API in Windows Vista that is now usable as a replacement. It
simplifies the code substantially, while returning nearly the same
result (on my system, the performance counters were 6 seconds behind).
The old code also did not work on Wine-5.0 (where I observed that
`data_size == data_block->HeaderLength`, and so no data was present).
The test is very flaky, both on the CI and on people's local machines.
I spent some time trying to fix it but its design is fairly questionable
and it fails to test what it should more often than not because on fast
machines no queueing of data takes place.
Fixes#2307.
- Add `Makefile` for example codes. (cherry-pick from old uvbook repo)
- Add a new example "Default loop" to "Basics of libuv"/"Default loop"
- Document review and update: `Introduction`, `Basics of libuv`, `Filesystem`
+ Update the referenced libuv code snippet
+ Link update: http->https
**Content Updates**:
- `filesystem.rst`#L291-L297: Add note for `uv_fs_event_start`
- `filesystem.rst`#L334: Add description of the callback function parameter `status`
The following examples have been tested manually in WSL2 (Ubuntu 20.04) with libuv 1.42.0:
- helloworld
- default-loop
- idle-basic
- uvcat
- uvtee
- onchange (test on macOS)
Co-authored-by: Nikhil Marathe <nsm.nikhil@gmail.com>
Disable `atime` testing for symlink as this test
is dependant on a race condition on some OSes
(Linux is one) as `lstat` updates the `atime`.
As both `mtime` and `atime` are set by the same
syscall, barring an eventual kernel bug, this
test does not omit any error case.
This adds a workaround for an xnu kernel bug that sometimes results in
SIGCHLD not being delivered. The workaround is to use kevent to listen
for EVFILT_PROC/NOTE_EXIT events instead of relying on SIGCHLD on *BSD.
Apple rdar: FB9529664
Refs: https://github.com/libuv/libuv/pull/3257
The process title mutex was destroyed on library unload without ensuring
it was initialized - and it may not be because it's initialized lazily.
On most platforms it worked by accident because an "all zeroes" mutex is
synonymous with an initialized and unlocked mutex, but not on NetBSD.
Refs: https://github.com/libuv/libuv/pull/3286#issuecomment-1014058782
uv_thread_create_ex() lets you set a stack size that is smaller than is
safe. It enforces a lower bound of PTHREAD_STACK_MIN (when that constant
is defined) but with musl libc that's still too small to receive signals
on.
Put the lower bound at 8192 or PTHREAD_STACK_MIN, whichever is greater.
The same restriction was already in place for the _default_ stack size.
The maximum numbers receivable by the recvmmsg call is defined in
src/unix/udp.c as UV__MMSG_MAXWIDTH with the current value being 20.
Align the size of the receive buffer in the mmsg test to receive the
maximum number of UDP packets in the test.
With MUSL libc, the struct msghdr is padded to align with the types used
in the Linux kernel headers (int vs size_t). When the padding was not
zeroed, the syscall would return EMSGSIZE because the random bytes in
the padding would be read by kernel as part of the size_t type.
Fixes: https://github.com/libuv/libuv/issues/3416
Currently it's checking pointers to the uv_buf_t fields match the size
of the iovec fields. This is true on traditional architectures where
pointers are just machine word-sized integers, but not on CHERI, and
thus Arm's Morello prototype, where pointers contain additional metadata
(including bounds and permissions). Drop the & to fix this.
macOS versions 10.10 and 10.15 - and presumbaly 10.11 to 10.14, too -
have a bug where a race condition causes the kernel to return EPROTOTYPE
because the socket isn't fully constructed.
It's probably the result of the peer closing the connection and that is
why libuv translates it to ECONNRESET.
Previously, libuv retried until the EPROTOTYPE error went away but some
VPN software causes the same behavior except the error is permanent, not
transient, turning the retry mechanism into an infinite loop.
Refs: https://github.com/libuv/libuv/pull/482
Refs: https://github.com/libuv/libuv/pull/3405
It's been reported in the past that OS X 10.10, because of a race
condition in the XNU kernel, sometimes returns a transient EPROTOTYPE
error when trying to write to a socket. Libuv handles that by retrying
the operation until it succeeds or fails with a different error.
Recently it's been reported that current versions of the operating
system formerly known as OS X fail permanently with EPROTOTYPE under
certain conditions, resulting in an infinite loop.
Because Apple isn't exactly forthcoming with bug fixes or even details,
I'm opting to simply remove the workaround and have the error bubble up.
Refs: https://github.com/libuv/libuv/pull/482
Changes since version 1.42.0:
* run test named ip6_sin6_len (Jameson Nash)
* docs: fix wrong information about scheduling (Mohamed Edrah)
* unix: protect fork in uv_spawn from signals (Jameson Nash)
* drop only successfully sent packets post sendmmsg (Supragya Raj)
* test: fix typo in test-tty-escape-sequence-processing.c (Ikko
Ashimine)
* cmake: use standard installation layout always (Sylvain Corlay)
* win,spawn: allow UNC path with forward slash (earnal)
* win,fsevent: fix uv_fs_event_stop() assert (Ben Noordhuis)
* unix: remove redundant include in unix.h (
* doc: mark SmartOS as Tier 3 support (
* doc: fix broken links for netbsd's sysctl manpage (
* misc: adjust stalebot deadline (
* test: remove `dns-server.c` as it is not used anywhere (
* build: fix non-cmake android builds (
* doc: replace pyuv with uvloop (
* asan: fix some tests (
* build: add experimental TSAN configuration (
* pipe: remove useless assertion (
* bsd: destroy mutex in uv__process_title_cleanup() (
* build: add windows build to CI (
* win,fs: fix error code in uv_fs_read() and uv_fs_write() ( Sen)
* build: add macos-latest to ci matrix (
* udp: fix &/&& typo in macro condition (
* build: install cmake package module (Petr Menšík)
* win: fix build for mingw32 (
* build: fix build failures with MinGW new headers (erw7)
* build: fix win build with cmake versions before v3.14 (
* unix: support aarch64 in uv_cpu_info() (
* linux: work around CIFS EPERM bug (
* sunos: Oracle Developer Studio support (
* Revert "sunos: Oracle Developer Studio support (
* sunos: Oracle Developer Studio support (
* stream: permit read after seeing EOF (
* thread: initialize uv_thread_self for all threads (
* kqueue: ignore write-end closed notifications (
* macos: fix the cfdata length in uv__get_cpu_speed ( Bache)
* unix,win: add uv_ip_name to get name from sockaddr (
* win,test: fix a few typos (AJ Heller)
* zos: use destructor for uv__threadpool_cleanup() ( Zhang)
* linux: use MemAvailable instead of MemFree (
* freebsd: call dlerror() only if necessary (
* bsd,windows,zos: fix udp disconnect EINVAL (
On z/OS, instead of calling the uv__threadpool_cleanup() function from
inside uv_library_shutdown(), the destructor attribute must be used;
otherwise, tests will fail with exit code 1 and no output. Additionally,
post() does not need to be called when the destructor attribute is used.
Also adds uv__os390_cleanup() function to clean System V message queue
on z/OS.
Co-authored-by: Igor Todorovski <itodorov@ca.ibm.com>
Co-authored-by: Gaby Baghdadi <baghdadi@ca.ibm.com>
We observed crashes inside CFRelease in uv__get_cpu_speed on the new
Mac Book Pro (arm) hardware. The problem is that the stack got
clobbered. On the new mac hardware the returned length is 8.
For the 4 byte case, a temp variable is used to avoid having to add
endian-sensitive offsets.
Fixes: https://github.com/libuv/libuv/issues/3355
The combination EVFILT_WRITE+EV_EOF is valid and indicates that the
reader has disconnected (called `shutdown(SHUT_RD)`). Probably very rare
in practice, but this seems more correct.
Issue noticed (for UV_DISCONNECT clients of uv_poll), while doing
research for https://github.com/libuv/libuv/pull/3250.
In particular, previously the main thread would have an id of NULL,
which was then not valid to use with any other API that expected a
uv_thread_t handle.
