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>
The file is implicitly unregistered when the change notification is
sent, only one notification is sent per registration. So we need to
re-register interest in a file after each change notification we
receive.
Co-authored-by: Gaby Baghdadi <baghdadi@ca.ibm.com>
On illumos and Solaris, fs events are implemented with
PORT_SOURCE_FILE type event ports. These are one-shot so
need re-arming each time they fire. Once they are armed
and an event occurs, the kernel removes them from the current
cache list and puts them on an event queue to be read by
the application.
There's a window in closing one of these ports when it could
have triggered and be pending delivery. In that case, the
attempt to disarm (dissociate) the event will fail with ENOENT
but libuv still goes ahead and closes down the handle. In
particular, the close callback (uv_close() argument) will be
called but then the event will subsequently be delivered if
the loop is still active; this should not happen.
This commit adds the support for a custom strtok implementation, which
is reentrant. On some systems strtok_r or strstep is available for that
purpose; however, since these are an extension, it is difficult to
control if it will be available on every supported system.
