Dynamic loading with musl only works with libc.so because it is
is implemented in musl's dynamic linker, not in libc proper.
libc.a contains just a stub dlopen() that always fails with a "Dynamic
loading not supported" error message. Update the test to handle that.
Fix: https://github.com/libuv/libuv/issues/3706
Another thread can change the working directory between calls to
GetCurrentDirectoryW().
The first call was used to determine the size of the buffer to use in
the second call. Retry if the reported size does not match the expected
size because the buffer's contents is undefined in that case.
uv_exepath() wrote the nul byte *after* the end of the buffer. It's not
necessary to write said nul byte in the first place because that was a
workaround for a bug in the Windows XP version of GetModuleFileName().
Fix uv_cwd() in the same fashion, it doesn't need the nul byte either.
Fixes: https://github.com/libuv/libuv/issues/3691
After analysis of many real-world programs I've come to conclude that
accepting in a loop is nearly always suboptimal.
1. 99.9% of the time the second accept() call fails with EAGAIN, meaning
there are no additional connections to accept. Not super expensive
in isolation but it adds up.
2. When there are more connections to accept but the listen socket is
shared between multiple processes (ex. the Node.js cluster module),
libuv's greedy behavior necessitated the UV_TCP_SINGLE_ACCEPT hack
to slow it down in order to give other processes a chance.
Accepting a single connection and relying on level-triggered polling to
get notified on the next incoming connection both simplifies the code
and optimizes for the common case.
This was a kludge for a bug in old versions (API level <= 16) of the
Android SDK.
The os390 port had a build dependency on the file but does not actually
use it so that too has been removed.
Split this off from endgame, so that it can be handled separately and
earlier, rather than trying to detect inside endgame which case we are
in. There appear to be some race conditions on the `handle` field still
however, which this does not yet attempt to address.
Some setsockopt() implememantations may return with errno of EINVAL
when the socket has been shut down already, as documented in the
Open Group Specifications Issue 7, 2018.
When this happens, reset errno and continue to mark the socket closed
and handle any callback.
Port the changes made to AIX and other unix systems in #611 to z/OS.
Defers the signal watcher that is used for process management until
after the dispatch of regular i/o watchers.
Refs: https://github.com/libuv/libuv/pull/611
Co-authored-by: Igor Todorovski <itodorov@ca.ibm.com>
Once the write queue is empty, we can fire the event immediately,
without needing a lot of syscalls and then waiting for the kernel to
feed us the event on the next tick. This also makes it more similar to
how it would behave if there was a write still in the queue also, which
we dispatch later in the same event loop iteration, then drain.
EINTR is explicitly documented as a possible error code of tcsetattr().
The documentation for tcgetattr() is silent on the subject but better
safe than sorry.
Fixes: https://github.com/libuv/libuv/issues/3645
The UV_ECANCELED codepath had an incorrect comment, and the
implementation was generally less robust (for example, not checking if
`cb` was NULL), so we can merge these codepaths for cleaner code.
The errno value is only meaningful if bind() fails and returns -1.
Some bind() implementations may return success but modify errno value
internally, like the socket_wrapper library used by the Samba testsuite.
This fixes an early exit bug in z/OS implementation of epoll_wait(),
resulting in some file events not being correctly captured.
The problem is that reventcount should only be incremented by 1, because
_NFDS counts as 1 even for fds with multiple revents set.
Also makes a few minor improvements to remove redundant checks.
Co-authored-by: Igor Todorovski <itodorov@ca.ibm.com>
Fixes an issue where under certain conditions, dynamically allocated
ip addresses, strings, and buffers were either leaking memory, being
incorrectly freed, or not performing error checks.
Also fixes an issue where the uv_interface_address_t struct was not
correctly initialized to 0, so use calloc() instead of malloc().
Co-authored-by: Igor Todorovski <itodorov@ca.ibm.com>
Use SIOCGIFNETMASK ioctl to retrieve the netmask for IPv4. However, this
approach is not supported for IPv6.
For IPv6 netmask, z/OS currently only provides the prefix length through
the __nif6e_prefixlen in __net_ifconf6entry_t struct, but this can be
used to calculate the IPv6 netmask similar to android implementation.
Co-authored-by: Igor Todorovski <itodorov@ca.ibm.com>
On z/OS, the interface address name contains EBCDIC and may be padded
with whitespaces. The whitespace padding needs to be trimmed, and the
interface address name needs to be converted from EBCDIC to ASCII.
Co-authored-by: John Barboza <jbarboza@ca.ibm.com>
Co-authored-by: Igor Todorovski <itodorov@ca.ibm.com>
On z/OS, fs events are implemented by registering file interest. When
closing a fs event handle, it's possible that a change notification has
already been generated. In that case, the attempt to unregister file
interest will fail with EALREADY. This will result in the fs event being
delivered even though the handle is closing, which should not happen.
Fixes: https://github.com/libuv/libuv/issues/3601
On z/OS, EPERM is returned if the process being killed is a zombie.
However, this shouldn't be treated as an error, so return 0 instead.
Co-authored-by: Muntasir Mallick <mmallick@ca.ibm.com>
Co-authored-by: Gaby Baghdadi <baghdadi@ca.ibm.com>
On NetBSD with libuv 1.44.1 we see that cmake occasionally hangs
waiting for a child process to exit, with libuv waiting forever for
`kevent` to deliver more events that never come. The child process has
already exited and is waiting to be collected with `waitpid`.
The hang occurs when the batch of events returned by one call to
`kevent` contains both a EVFILT_READ event for an fd and a later
EVFILT_PROC record for the PID with the same value as the earlier fd.
What happens is that `uv__platform_invalidate_fd` is called to
invalidate events later in the same batch for the fd, but
`uv__platform_invalidate_fd` invalidates the later EVFILT_PROC event
too because it sees the same "ident" value and does not check the
"filter" value to differentiate "ident" values that refer to fds vs.
"ident" values that refer to PIDs.
Add a check for the "filter" value to avoid confusing these two
different kinds of event "ident" values.
Previously, Windows would always defer event processing to the loop
after they were received. This could cause confusion for users who were
using prepare and idle callbacks, as seen from this bug in nodejs[^1] and
this discussion in libuv[^2], and even some discrepancies in the libuv
tests too[^3].
[^1]: https://github.com/nodejs/node/pull/42340
[^2]: https://github.com/libuv/libuv/discussions/3550
[^3]: See change to test-spawn.c in this PR
So rather than declare those usages to be wrong, we change libuv to meet
those users expectations.
Replaces: https://github.com/libuv/libuv/pull/3585
If `uv_close` was called while a connect was pending, we would fail to
release the resources for the connection, since we had not yet set the
type of the struct.
Fix a thread data-race on slow connect path code: only permitted to
write to `req` on threads, as anything else causes data race
corruption.
There seemed be a small variety of other resource management bugs in
edge cases, which turned out to make this a lot larger than initially
expected.
Refs: https://github.com/libuv/libuv/pull/3598#issuecomment-1111513567
This test has always been disabled for the 10 years of its existence and
there are other tests that exercise "what happens when" event ordering.
Fixes: https://github.com/libuv/libuv/issues/3618
Use MSG_CMSG_CLOEXEC on Unix-y platforms that support it (all except
macOS and SunOS spawn.)
Remove the feature test for Linux. Libuv's kernel baseline is 2.6.32
and MSG_CMSG_CLOEXEC was added in 2.6.23.
Use libtoolize --force to ensure it updates m4 directory with the
latest files. Add an option "release" to the autogen.sh script that
checks the versions of the input tools, so that we know they are always
using the latest version for each release.
macOS 10.15 has a bug where configuring the working directory with
posix_spawn_file_actions_addchdir_np() makes posix_spawnp() fail with
ENOENT even though the executable is spawned successfully.
Co-authored-by: Ben Noordhuis <info@bnoordhuis.nl>
When the watched file is moved or removed, or an editor (e.g. vim)
renames then creates the file, the __rfim_event 156 occurs. This is an
undocumented event that should not happen, but register it as UV_RENAME
for now since it is functionally equivalent.
Co-authored-by: Gaby Baghdadi <baghdadi@ca.ibm.com>
`rename()` can be used to rename a file path via _RFIM_UNLINK. So
register it as a UV_RENAME event.
Co-authored-by: Igor Todorovski <itodorov@ca.ibm.com>