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.
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>
