The worker pool calls all callbacks locally within the queue. So the
value of nevents doesn't properly reflect that case. Increase the number
of events directly from the worker pool's callback to correct this.
In order to properly determine if the events_waiting counter needs to be
incremented, store the timeout value at the time the event provider was
called.
The signal_multiple_loops test is flaky when run under AddressSanitizer
and MemorySanitizer. Sometimes thread creation fails, other times it
simply times out.
Fixes: https://github.com/libuv/libuv/issues/3956
Add io_uring support for several asynchronous file operations:
- read, write
- fsync, fdatasync
- stat, fstat, lstat
io_uring is used when the kernel is new enough, otherwise libuv simply
falls back to the thread pool.
Performance looks great; an 8x increase in throughput has been observed.
This work was sponsored by ISC, the Internet Systems Consortium.
Fixes: https://github.com/libuv/libuv/issues/1947
Don't use a static buffer to hold human-readable "big" numbers.
The buffer isn't big enough for benchmarks like fs_stat that print a
large number of them. Have the caller pass in a buffer instead.
The maximum number of times timers should run when uv_run() is called
with UV_RUN_ONCE and UV_RUN_NOWAIT is 1. Do that by conditionally
calling timers before entering the while loop when called with
UV_RUN_DEFAULT.
The reason to always run timers at the end of the while loop, instead of
at the beginning, is to help enforce the conceptual event loop model.
Which starts when entering the event provider (e.g. calling poll).
Other than only allowing timers to be processed once per uv_run()
execution, the only other noticeable change this will show is if all the
following are true:
* uv_run() is called with UV_RUN_NOWAIT or UV_RUN_ONCE.
* An event is waiting to be received when poll is called.
* Execution time between the call to uv_timer_start() and entering the
while loop is longer than the timeout.
If all these are true, then timers that would have executed before
entering the event provider will now be executed afterward.
Fixes: https://github.com/libuv/libuv/issues/3686
Co-authored-by: Momtchil Momtchev <momtchil@momtchev.com>
Pass the loop to MAKE_VALGRIND_HAPPY() so it's explicit on which loop
needs to be cleaned up. Since it asserts on uv_loop_close(), need to
remove a couple of those that were being done before the call.
Cleanup where loop was assigned, so the entire test either uses loop or
uv_default_loop(). Not both.
Also take care of any reqs that may have been left uncleaned.
This code would previously get confused between rounds of the barrier
being called and a thread might incorrectly get stuck (deadlock) if the
next round started before that thread had exited the current round.
Avoid that by not starting the next round in++ before out-- has reached
zero indicating that all threads have left the prior round.
And fix it that on Windows by replacing the implementation with the one
from unix. There are some awkward platform-specific redirection here
with an extra malloc that is not needed on Win32, but that will be fixed
in libuv v2.
Fixes: https://github.com/libuv/libuv/issue/3872
Remove expectations around uv_cond_timedwait() maximum sleep time.
The OpenBSD buildbot sleeps more than 5x longer than requested. It no
longer makes sense to expect some reasonable upper bound because at that
point we've moved well beyond reasonable.
Fixes: https://github.com/libuv/libuv/issues/3896
When run under distcheck, the libuv source permissions are read-only,
which makes this test copyfile fail without explicit correction to the
permissions.
ThreadSanitizer's complaints about data races are likely legitimate but
they are pre-existing and not straightforward to fix with the current
design. Something for later.
Refs: https://github.com/libuv/libuv/issues/3681
Legitimate if fairly benign warning: the `stop` global variable was
read and written without proper synchronization; `volatile` isn't
sufficient.
Refs: https://github.com/libuv/libuv/issues/3681
```
warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
note: in expansion of macro 'ASSERT_BASE'
#define ASSERT_EQ(a, b) ASSERT_BASE(a, ==, b, int64_t, PRId64)
warning: format ‘%lx’ expects argument of type ‘long unsigned int’, but
argument 3 has type ‘uint32_t’ {aka ‘unsigned int’}
```
Co-authored-by: Jameson Nash <vtjnash@gmail.com>
File system operations may return uid and gid values, which we may want
to pretty-print. We already have the code for getting information for
the current user, so just need to add a parameter to make it exposed for
every user. We expose information about groups in a similar manner also.
In Node.js, fs.readlink() on a non-symlink file used to throw an UNKNOWN
error on Windows. This change maps ERROR_NOT_A_REPARSE_POINT to
UV_EINVAL, so that now it throws EINVAL just like other platforms.
This is handled explicitly in `fs__readlink`, since elsewhere it might
map to EPERM instead (such as in `link`).
Increase the timer interval. That hopefully ameliorates the problem of
FSEvents.framework missing events on the macOS CI buildbot.
Not really a fix, more a mitigation.
Fixes: https://github.com/libuv/libuv/issues/3862
Return `UV_EAGAIN` on `ERROR_OPERATION_ABORTED`.
Use the correct format for `overlapped.hEvent`.
Some refactoring to always wait for the overlapped result.
Modernize tests and some improvements.
Calling uv_fs_fstat for file types other then disk type was resulting in
error on Windows while it was retrieving data on Linux. This change
enables getting fstat for pipes and character files on Windows with data
fetched being as reasonable as possible.
A simple test is also added to check this behavior on all platforms. It
uses stdin, stdout and stderr. uv_fs_fstat needs to pass with disk files
pipes and character files (eg. console).
Refs: https://github.com/nodejs/node/issues/40006
Co-authored-by: Jameson Nash <vtjnash@gmail.com>
The following metrics are now always recorded and available via the new
uv_metrics_info() API.
* loop_count: Number of event loop iterations.
* events: Total number of events processed by the event handler.
* events_waiting: Total number of events waiting in the event queue when
the event provider request was made.
Benchmarking has shown no noticeable impact recording these metrics.
PR-URL: https://github.com/libuv/libuv/pull/3749
Make unices and windows consistent when closing a pipe while it's
connecting so they all return `UV_ECANCELED`.
Avoid race condition between `pipe_connect_thread_proc()` and `uv_close()` when
accessing `handle->name`.
Fixes: https://github.com/libuv/libuv/issues/3578
So `WaitNamedPipe()` doesn't fail. Increase the number of clients in
`pipe_connect_multiple` so `CreateFile()` returns `ERROR_PIPE_BUSY` and
the codepath leading to `WaitNamedPipe()` is exercised.
Backported thread affinity feature and related dependency commits
from master. It will add support for those APIs: uv_cpumask_size,
uv_thread_setaffinity, uv_thread_getaffinity.
The supported platforms are Linux, Freebsd, and Windows.
Empty implementations (returning UV_ENOTSUP) on non-supported platforms
(such as OS X and AIX).
- unpoison results from linux system call wrappers
- unpoison results from stat/fstat/lstat to pacify clang 14
(fixed in later versions)
- add MSAN build option
- turn on MSAN CI build
uv_fs_scandir() leaked an entry when you called it on a directory with
a single entry _and_ you didn't run the iterator until UV_EOF.
Fixes: https://github.com/libuv/libuv/issues/3748
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
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.
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
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
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>
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.
Replacement for the usage pattern where people use uv_cpu_info() as an
imperfect heuristic for determining the amount of parallelism that is
available to their programs.
Fixes#3493.
Added in https://github.com/libuv/libuv/pull/742, these values are
typically defined as unsigned (since Linux 2.4). Only -1 is special,
representing an invalid id (e.g. see setreuid).
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
- 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)
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.
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
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.
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.
On some streams (notably TTYs), it is permitted to continue reading
after getting EOF. So still stop reading on EOF, but allow the user to
reset the stream and try to read again (which may just get EOF).
This relaxes the constraint added in ce15b8405e.
Refs: https://github.com/libuv/libuv/pull/3006
Oracle Developer Studio requires public functions to be
defined as "__global" when "-fvisibility=hidden" used as
added by [#3005](https://github.com/libuv/libuv/pull/3005).
For documentation on `__global` see Reducing Symbol Scope in
Oracle Developer Studio C/C++ guide
https://www.oracle.com/solaris/technologies/symbol-scope.html.
fs_utime_round test failed as timespec.tv_nsec conversion to
double resulted in negative number. Skip this test for
__SPRO_C builds.
Note that it was necessary to have C99 language features
enabled with Studio compiler (-xc99=all) as version v1.41.0
has other commits that have used C99 features.
Tested with:
- cc: Studio 12.6 Sun C 5.15 SunOS_sparc 152881-05 2019/10/30
- gcc (GCC) 11.2.0
Refs: https://github.com/libuv/libuv/pull/3364
Oracle Solaris linker visibility support. Option "-fvisibility=hidden"
requires public functions to be defined as "__global".
fs_utime_round test failed as timespec.tv_nsec conversion to double
resulted in negative number. Skipped this test.
Note that it was necessary to compile with C99 language features.
Just like the Unix counterpart, uv_fs_read() and uv_fs_write() should
throw an EBADF instead of throwing an EPERM when the passed fd has not
been opened with the right flags.
Signed-off-by: Darshan Sen <darshan.sen@postman.com>
Previously they were just being run incorrectly, but nothing wrong with
the test itself. We were also interpreting an ASAN failure as TEST_SKIP,
so test failures would not actually be reported as CI failures.
Fix a logic error where calling uv_fs_event_stop() from the event
callback tripped on a `handle->dir_handle != INVALID_HANDLE_VALUE`
assert in uv_fs_event_queue_readdirchanges().
Fixes: https://github.com/libuv/libuv/issues/3258
PR-URL: https://github.com/libuv/libuv/pull/3259
Reviewed-By: Jameson Nash <vtjnash@gmail.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
postion -> position in several comments
PR-URL: https://github.com/libuv/libuv/pull/3284
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Jameson Nash <vtjnash@gmail.com>
While most users will likely typically call uv_close in their
uv_shutdown callback, some callers (notable nodejs) do not always do
so. This can result in libuv keeping the loop active, even though there
are no outstanding reqs left to handle.
This bug was added in 80f2f826bf, where
the premise of that commit appears to have simply been incorrect, as
demonstrated by the added test.
Refs: https://github.com/libuv/libuv/issues/3202
PR-URL: https://github.com/libuv/libuv/pull/3233
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
libuv was vulnerable to out-of-bounds reads in the uv__idna_toascii()
function which is used to convert strings to ASCII. This is called by
the DNS resolution function and can lead to information disclosures or
crashes.
Reported by Eric Sesterhenn in collaboration with Cure53 and ExpressVPN.
Reported-By: Eric Sesterhenn <eric.sesterhenn@x41-dsec.de>
Fixes: https://github.com/libuv/libuv/issues/3147
PR-URL: https://github.com/libuv/libuv-private/pull/1
Refs: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-22918
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
This is an attempt to fix some resource management issues on Windows.
Win32 sockets have an issue where it sends an RST packet if there is an
outstanding overlapped calls. We can avoid that by being certain to
explicitly cancel our read and write requests first.
This also removes some conditional cleanup code, since we might as well
clean it up eagerly (like unix). Otherwise, it looks to me like these
might cause the accept callbacks to be run after the endgame had freed
the memory for them.
The comment here seems mixed up between send and recv buffers. The
default behavior on calling `closesocket` is already to do a graceful
shutdown (see
https://docs.microsoft.com/en-us/windows/win32/api/winsock/nf-winsock-closesocket
with default l_onoff=zero) if it is the last open handle. The expected
behavior if there are pending reads in flight is to send an RST packet,
notifying the client that the server connection was destroyed before
acknowledging the EOF.
Additionally, we need to cancel writes explicitly: we need to notify
Win32 that it is okay to cancel these writes (so it doesn't also
generate an RST packet on the wire).
Refs: https://github.com/libuv/libuv/pull/3035
Refs: https://github.com/nodejs/node/pull/35946
Refs: https://github.com/nodejs/node/issues/35904
Fixes: https://github.com/libuv/libuv/issues/3034
PR-URL: https://github.com/libuv/libuv/pull/3036
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Just like the unix counterpart, uv_fs_read and uv_fs_write should throw
an EBADF instead of manually throwing an EPERM when the passed fd has
not been opened with the right access flags.
PR-URL: https://github.com/libuv/libuv/pull/3180
Reviewed-By: Jameson Nash <vtjnash@gmail.com>
The TAP specification [1] explicitely states:
A harness must only read TAP output from standard output and
not from standard error.
[1] https://testanything.org/tap-specification.html
PR-URL: https://github.com/libuv/libuv/pull/3153
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Jameson Nash <vtjnash@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
In both `test-tcp-open` and `test-udp-open`.
PR-URL: https://github.com/libuv/libuv/pull/3137
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
In the codebase we have used empty for loop for infinite conditions, so
to bring consistency replaced other occurrences of while in the codebase
with for loop.
PR-URL: https://github.com/libuv/libuv/pull/3128
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
To properly handle sending UDP packet to unreachable address.
PR-URL: https://github.com/libuv/libuv/pull/2872
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
This commit introduces ZOSLIB for z/OS, which is a C/C++ library that
implements additional POSIX APIs not available in the LE C Runtime
Library, and provides API for EBCDIC <-> ASCII conversion. This library
requires the linker to be set to CXX when building for z/OS. ZOSLIB is
designed to be installed separately, and then linked to libuv with the
`-DZOSLIB_DIR` option.
PR-URL: https://github.com/libuv/libuv/pull/3060
Reviewed-By: Richard Lau <rlau@redhat.com>
Nanosecond resolution for the timestamp fields `st_atim`, `st_mtim`, and
`st_ctim` are not supported on z/OS.
PR-URL: https://github.com/libuv/libuv/pull/3060
Reviewed-By: Richard Lau <rlau@redhat.com>
Moving to new style test macros will make debugging easier in case
of test failure and improve redability. This commit will replace all
ASSERT macros matching the statement:
`ASSERT(identifier (== or !=) value);`
to:
`ASSERT_(NOT_)NULL(identifier);`
Refs: https://github.com/libuv/libuv/issues/2974
PR-URL: https://github.com/libuv/libuv/pull/3081
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Consider the following scenario:
uv_poll_init(loop, poll, fd);
uv_poll_start(poll, UV_READABLE, cb);
// the cb gets invoked etc.
uv_poll_stop(poll);
close(fd);
fd = allocate_new_socket(); // allocate_new_socket() is assigned the same fd by "bad luck" from the OS
// some time later:
uv_poll_init(loop, otherpoll, fd);
uv_poll_start(otherpoll, UV_READABLE, cb);
uv_close(poll); // uv__io_stop: Assertion `loop->watchers[w->fd] == w' failed.
According to documentation, "however the fd can be safely closed
immediately after a call to uv_poll_stop() or uv_close()."
Though, in this scenario, we close()'d our file descriptor, and by
bad luck we got the same file descriptor again and register a new
handle for it and start polling.
Previously that would lead to an assertion failure, if we were to
properly free the original handle via uv_close().
This commit fixes that by moving the check whether a only a single
poll handle is active to uv_poll_start() instead of the stopping
routines.
Fixes: https://github.com/libuv/libuv/issues/1172
Fixes: https://github.com/bwoebi/php-uv/issues/81
Fixes: https://github.com/b2wdigital/aiologger/issues/82
Fixes: https://github.com/invenia/LibPQ.jl/issues/140
PR-URL: https://github.com/libuv/libuv/pull/2686
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Jameson Nash <vtjnash@gmail.com>
* Windows 7 went out of support earlier this year.
* As did Python 2.7. We no longer have to worry about MSVC 2008.
Python 3.5 and up use VS 2015.
PR-URL: https://github.com/libuv/libuv/pull/2821
Reviewed-By: Bartosz Sosnowski <bartosz@janeasystems.com>
Reviewed-By: Jameson Nash <vtjnash@gmail.com>
Reviewed-By: Joao Reis <reis@janeasystems.com>
RFC 2606 reserves the .invalid top-level domain for this purpose.
PR-URL: https://github.com/libuv/libuv/pull/3063
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
`uv_fs_utime()` and `uv_fs_futime()` receive the timestamp as
a `double` and then convert it to `struct timeval` or `struct timespec`
where necessary but the calculation for the sub-second part exhibited
rounding errors for dates in the deep past or the far-flung future,
causing the timestamps to be off by sometimes over half a second on
unix, or to be reinterpreted as unsigned and end up off by more than
just sign but many also decades.
Fixes: https://github.com/nodejs/node/issues/32369 (partially)
PR-URL: https://github.com/libuv/libuv/pull/2747
Co-authored-by: Jameson Nash <vtjnash@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
`check_utime()` already calls `uv_fs_stat()`, no point in doing it
twice.
PR-URL: https://github.com/libuv/libuv/pull/2747
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Equivalents of `pipe` and `socketpair` for cross-platform use.
PR-URL: https://github.com/libuv/libuv/pull/2953
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Return `UV_EINVAL` when one or more arguments are NULL.
Fixes: https://github.com/libuv/help/issues/137
PR-URL: https://github.com/libuv/libuv/pull/2795
Reviewed-By: Jameson Nash <vtjnash@gmail.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Bartosz Sosnowski <bartosz@janeasystems.com>
The behavior of `uv_read_start()` when the handle is closing or already
busy reading wasn't consistent across platforms. Now it is.
Fixes: https://github.com/libuv/help/issues/137
PR-URL: https://github.com/libuv/libuv/pull/2795
Reviewed-By: Jameson Nash <vtjnash@gmail.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Bartosz Sosnowski <bartosz@janeasystems.com>
Fix a bug where libuv forgets about EADDRINUSE errors reported earlier:
uv_tcp_bind() + uv_tcp_connect() seemingly succeed but the socket isn't
actually bound to the requested address.
This bug goes back to at least 2011 if indeed it ever worked at all.
PR-URL: https://github.com/libuv/libuv/pull/2218
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Reviewed-By: Jameson Nash <vtjnash@gmail.com>
On Windows when connecting to an unavailable port, the connect() will
retry for 2s, even on loopback devices. This uses a call to WSAIoctl to
make the connect() call fail instantly on local connections.
PR-URL: https://github.com/libuv/libuv/pull/2896
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Reviewed-By: Jameson Nash <vtjnash@gmail.com>
Passing expression as an argument to a function-like macro will replace
all occurrence of the arguments with expressions during preprocessing.
This result in multiple evaluation of the same expression and can
slow-down the program or even change program state. Here ASSERT_BASE
macro gets an expression involving a and b as first argument and macro
definition has a print statement with a and b, which means there is
double evaluation of a and b when the expression evaluates to false. To
avoid double evaluation temporary variables are created to store results
of a and b.
Since the expression argument is dropped from ASSERT_BASE, the macro no
longer works for string assertions. So a new macro, ASSERT_BASE_STR, is
introduced to deal with strings. ASSERT_BASE can still work with
pointers.
Fixes: https://github.com/libuv/libuv/issues/2916
PR-URL: https://github.com/libuv/libuv/pull/2926
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Jameson Nash <vtjnash@gmail.com>
Contents of template variable passed for posix call mkstemp on error
code EINVAL is unknown. On AIX platform, template will get clobbered
on EINVAL and any attempt to read template might result in error.
In libuv, req->path is passed directly to the mkstemp call and
behavior of this string on error is platform dependent. To avoid
portability issues, it's better to have a common behavior on all
platform. For both unix and windows platform libuv will rewrite path
with an empty string on all error cases.
Fixes: https://github.com/libuv/libuv/issues/2913
Refs: https://github.com/nodejs/node/pull/33549
Refs: https://github.com/libuv/libuv/pull/2933
PR-URL: https://github.com/libuv/libuv/pull/2938
Reviewed-By: Jameson Nash <vtjnash@gmail.com>
Store a copy of the original argv[0] to protect `uv_exepath()`
against `uv_set_process_title()` changing the value of argv[0].
Extract common code for finding a program on the current PATH.
Fixes: https://github.com/libuv/libuv/issues/2674
PR-URL: https://github.com/libuv/libuv/pull/2677
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Jameson Nash <vtjnash@gmail.com>
This commit handles the case where the source and destination
are the same. This behavior was originally addressed in #2298,
but the test added in that PR doesn't validate the file size
after the operation. This commit also updates the test to check
for that case.
Refs: https://github.com/libuv/libuv/pull/2298
Refs: https://github.com/nodejs/node/issues/34624
PR-URL: https://github.com/libuv/libuv/pull/2947
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Jameson Nash <vtjnash@gmail.com>
Libuv calls uv__process_title_cleanup() on shutdown, which raced with
one of the threads from the test that calls uv_get_process_title() in
an infinite loop. Change the test to properly shut down the thread
before exiting.
PR-URL: https://github.com/libuv/libuv/pull/2946
Refs: https://github.com/libuv/libuv/pull/2853#issuecomment-665259082
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Jameson Nash <vtjnash@gmail.com>
The API addition `uv_metrics_idle_time()` is a thread safe call that
allows the user to retrieve the amount of time the event loop has spent
in the kernel's event provider (i.e. poll). It was done this way to
allow retrieving this value without needing to interrupt the execution
of the event loop. This option can be enabled by passing
`UV_METRICS_IDLE_TIME` to `uv_loop_configure()`.
One important aspect of this change is, when enabled, to always first
call the event provider with a `timeout == 0`. This allows libuv to know
whether any events were waiting in the event queue when the event
provider was called. The importance of this is because libuv is tracking
the amount of "idle time", not "poll time". Thus the provider entry time
is not recorded when `timeout == 0` (the event provider never idles in
this case).
While this does add a small amount of overhead, when enabled, but the
overhead decreases when the event loop has a heavier load. This is
because poll events will be waiting when the event provider is called.
Thus never actually recording the provider entry time.
Checking if `uv_loop_t` is configured with `UV_METRICS_IDLE_TIME` always
happens in `uv__metrics_set_provider_entry_time()` and
`uv__metrics_update_idle_time()`. Making the conditional logic wrapping
each call simpler and allows for instrumentation to always hook into
those two function calls.
Rather than placing the fields directly on `uv__loop_internal_fields_t`
add the struct `uv__loop_metrics_t` as a location for future metrics API
additions.
Tests and additional documentation has been included.
PR-URL: https://github.com/libuv/libuv/pull/2725
Reviewed-By: Fedor Indutny <fedor.indutny@gmail.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Reviewed-By: Jameson Nash <vtjnash@gmail.com>
Allows for determining if a buffer large enough for multiple dgrams
should be allocated in alloc_cb of uv_udp_recvstart, for example.
Contributes towards #2822.
PR-URL: https://github.com/libuv/libuv/pull/2830
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Jameson Nash <vtjnash@gmail.com>
This fix avoids inserting a duplicate pending request in the case where
`WSARecv()` returns an error (e.g. when a connection has been terminated
by its peer) when `uv_read_start()` is called in a read callback.
Fixes: https://github.com/libuv/libuv/issues/2687
PR-URL: https://github.com/libuv/libuv/pull/2688
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Reviewed-By: Bartosz Sosnowski <bartosz@janeasystems.com>
Reviewed-By: Jameson Nash <vtjnash@gmail.com>
This issue manifested on `connected` udp sockets trying to send
datagrams to a non-existent server and returning `ECONNREFUSED` because
an ICMP error was received before the actual sending was performed.
PR-URL: https://github.com/libuv/libuv/pull/2899
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
This test was consistently timing out on macOS. Some printf()
debugging on the CI showed that the test was still making forward
progress, but legitimately timed out. This commit bumps the test
timeout to a value that should provide much more than enough time.
Fixes: https://github.com/libuv/libuv/issues/2775
PR-URL: https://github.com/libuv/libuv/pull/2865
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
This commit runs the test suite via QEMU on GitHub Actions on
a variety of platforms.
Fixes: https://github.com/libuv/libuv/issues/2842
PR-URL: https://github.com/libuv/libuv/pull/2846
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
