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.
It's been reported that copy_file_range() on a CIFS mount fails with
an EPERM error, even though the source and target files have the
appropriate permissions.
This is probably a variation on the EPERM error that libuv handles when
it tries to fchmod() a file on a CIFS mount that hasn't been mounted
with the "noperm" option, so let's handle it here too.
This commit applies minor refactoring because the "work around file
system bugs" section got quite unwieldy.
I also snuck in a bug fix where the workaround for buggy CephFS mounts
disabled copy_file_range() permanently.
Fixes: https://github.com/libuv/libuv/issues/3322
Before v3.14, cmake throws the following error:
```
CMake Error at third_party/libuv/CMakeLists.txt:663 (install):
install Library TARGETS given no DESTINATION!
```
I confirmed on Windows 7 and Windows Server 2016, with about a dozen
cmake versions between 3.7 and 3.22. I also confirmed that the
DESTINATION `${CMAKE_INSTALL_LIBDIR}` is populated with a valid path.
PR-URL: https://github.com/libuv/libuv/pull/3343
A structure definition was added to mstcpip.h in
mingw-w64-x86_64-headers-git 9.0.0.6327.f29c1101f,
which causes a conflict and the build fails. Fix this by
changing the name in the definition in mstcpip.h.
PR-URL: https://github.com/libuv/libuv/pull/3345
Commit e9c524aa from pull request https://github.com/libuv/libuv/pull/3149
introduced a hard dependency on `GetHostnameW`, which isn't declared
yet in mingw distributions (see
https://github.com/msys2/MINGW-packages/issues/9667).
This prevents the current version of libuv from building on many mingw
distributions, until such time the next version of mingw is released with
the correct definition for `GetHostnameW`, preventing a lot of projects
depending on libuv from building on mingw properly, as not all
distributions will update to head immediately anyway.
Instead of waiting, let's find the definition ourselves using
`GetProcAddress` and use the pointer instead.
PR-URL: https://github.com/libuv/libuv/pull/3340
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>
This assertion was added when req->write_buffer was a pointer. It was
then checking that write_buffer itself was not NULL. Checking that .base
is not NULL is superfluous because WriteFile will return error 998
(ERROR_NO_ACCESS) if the input buffer is invalid. This assertion fires
on zero-length writes when base==NULL&&len==0.
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>
sendmmsg returns with number of packets sent which can
be less than number of packets requested to be sent. Do
not flush entire write queue and use the returned info
to partially clear the write queue.
Refs: https://github.com/libuv/libuv/issues/3129 (fixes one issue listed)
PR-URL: https://github.com/libuv/libuv/pull/3265
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Years ago, we found that various kernels (linux, macOS) were known to
fail if they try to deliver a signal during this syscall, so we prevent
that from happening. They may have fixed those issues, but it is
generally just a bad time for signals to arrive (glibc blocks them here,
for example, including some more internal ones that it won't let us
touch here).
We try to be a bit conservative, and leave many signals unblocked which
could happen during normal execution and should terminate the process if
they do. There is a small race window after the child starts before we
clear the old handlers, if the user was to send an fake signal from
elsewhere, but that should be quite unlikely.
PR-URL: https://github.com/libuv/libuv/pull/3251
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
On illumos, the global errno variable is not thread-safe by default,
requiring that the application be built with gcc's -pthread option, or
that it defines -D_REENTRANT.
This was done already for the autotools build, but not for CMake.
PR-URL: https://github.com/libuv/libuv/pull/3243
Reviewed-By: Jameson Nash <vtjnash@gmail.com>
The sunos platform currently covers at least the Solaris and illumos
operating systems. Although these diverged 11 years ago they still share
some common features such as support for event ports.
illumos also has a compatibility wrapper for epoll but this is not
recommended for use over event ports. From the NOTES section of
https://illumos.org/man/5/epoll:
The epoll facility is implemented for purposes of offering
compatibility to and portability of Linux-borne
applications; native applications should continue to prefer
using event ports... In particular, use of epoll in a
multithreaded environment is fraught with peril...
Restore the event ports code so that libuv can continue to be used
on Solaris, and to avoid the problems that come with using epoll()
on illumos. The separation of epoll into src/unix/epoll.c has been
retained.
Fixes: https://github.com/libuv/libuv/issues/3241
PR-URL: https://github.com/libuv/libuv/pull/3242
Reviewed-By: Jameson Nash <vtjnash@gmail.com>
`strnlen` was not available on Solaris 10, so provide a fallback
implementation for it.
PR-URL: https://github.com/libuv/libuv/pull/3152
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Jameson Nash <vtjnash@gmail.com>
Don't use x86 inline assembly in these cases, but fall back to
__sync_fetch_and_or, similar to _InterlockedOr8 in the MSVC case.
This corresponds to what is done in src/unix/atomic-ops.h, where
ARM/AArch64 cases end up implementing cmpxchgi with
__sync_val_compare_and_swap.
PR-URL: https://github.com/libuv/libuv/pull/3236
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>
Prior to this patch a race condition may occur in case a thread tries
to destroy the barrier while other awaiting threads were not notified.
Since the internal mutex and condition variables are destroyed this may
cause an undefined behavior as described by the man pages.
So in order to prevent such scenarios the detroy function will not wait
until all awaiting threads are finished before proceeding.
Fixes: https://github.com/libuv/libuv/issues/3102
PR-URL: https://github.com/libuv/libuv/pull/3162
Reviewed-By: Jameson Nash <vtjnash@gmail.com>
uv_tty_set_mode() allows a tty device to be set to raw mode with
UV_TTY_MODE_RAW, which correctly sets MIN and TIME to appropriate
values for character input. When UV_TTY_MODE_IO is passed, on illumos
systems a compatibility implementation of cfmakeraw() is used that does
_not_ set MIN or TIME. As a result, consumers of IO mode will block
until a minimum of 4 bytes is available on the tty instead of just 1 as
is expected.
PR-URL: https://github.com/libuv/libuv/pull/3219
Reviewed-By: Jameson Nash <vtjnash@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>
