build: ubsan fixes (#4254)

MSVC does not actually support ubsan. There is a long-standing ticket
requesting this:
https://developercommunity.visualstudio.com/t/add-support-for-ubsan/

build: ubsan fixes (#4254)

MSVC does not actually support ubsan. There is a long-standing ticket
requesting this:
https://developercommunity.visualstudio.com/t/add-support-for-ubsan/840750

There are no known compilers that currently accept the
`/fsanitize=undefined` spelling. clang-cl accepts `-fsanitize...`,
same as regular clang.

Also passes no-sanitizer-recover so that tests actually fail.

Fix various ubsan-detected errors, including:

* win: fix req-inl.h ubsan failure

Don't use CONTAINING_RECORD macro from WinSDK, as it doesn't use the
right trick which avoids member access on null pointer.

Fixes:
```
src/win/req-inl.h:86:10: runtime error: member access within null pointer of type 'uv_req_t' (aka 'struct uv_req_s')
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior D:/a/libuv/libuv/src/win/req-inl.h:86:10
```

* test: fix ubsan failure on udp_ref3

Don't call functions through different function type.

Fixes:
```
src/win/udp.c:537:5: runtime error: call to function req_cb through pointer to incorrect function type 'void (*)(struct uv_udp_send_s *, int)'
test\test-ref.c:66: note: req_cb defined here
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior src/win/udp.c:537:5 in
```

* win: fix process-stdio.c ubsan failure

When accessing HANDLEs within the stdio buffer, use memcpy / memset in order to respect alignment.

Fixes:
```
src/win/process-stdio.c:197:5: runtime error: store to misaligned address 0x0230ee72d107 for type 'HANDLE' (aka 'void *'), which requires 8 byte alignment
0x0230ee72d107: note: pointer points here
00 00 cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd fd fd fd fd
^
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior src/win/process-stdio.c:197:5 in
```

* win: fix getaddrinfo.c ubsan failure

Reworks buffer alignment handling to respect requirements.

Fixes:
```
src/win/getaddrinfo.c:157:23: runtime error: member access within misaligned address 0x0290e4c6a17c for type 'struct addrinfo', which requires 8 byte alignment
0x0290e4c6a17c: note: pointer points here
00 00 00 00 cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd cd
^
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior src/win/getaddrinfo.c:157:23 in
```

* win: fix pipe.c ubsan failure

Changes "random" representation from pointer to number.

Fixes:
```
src/win/pipe.c:234:11: runtime error: applying non-zero offset to non-null pointer 0xffffffffffffffff produced null pointer
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior src/win/pipe.c:234:11 in
```

* unix: fix stream.c ubsan failure

Avoids performing pointer arithmetic on null pointer.

Fixes:
```
src/unix/stream.c:701:15: runtime error: applying zero offset to null pointer
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /Users/runner/work/libuv/libuv/src/unix/stream.c:701:15 in
```

show more ...

unix,win: remove unused req parameter from macros (#4435)

Remove the unused `req` parameter from the uv__req_register and
uv__req_unregister macros.

unix: fix fd leaks in SCM_RIGHTS error path (#4358)

The file descriptor leak in the inner path was pointed out by @theanarkh
and I subsequently spotted another one in the outer loop. Rew

unix: fix fd leaks in SCM_RIGHTS error path (#4358)

The file descriptor leak in the inner path was pointed out by @theanarkh
and I subsequently spotted another one in the outer loop. Rewrite the
function to process all control messages.

Refs: https://github.com/libuv/libuv/pull/4357

show more ...

unix,win: replace QUEUE with struct uv__queue (#4022)

Recent versions of gcc have started emitting warnings about the liberal
type casting inside the QUEUE macros. Although the warnings

unix,win: replace QUEUE with struct uv__queue (#4022)

Recent versions of gcc have started emitting warnings about the liberal
type casting inside the QUEUE macros. Although the warnings are false
positives, let's use them as the impetus to switch to a type-safer and
arguably cleaner approach.

Fixes: https://github.com/libuv/libuv/issues/4019

show more ...

unix: remove clang compiler warning pragmas (#3989)

Instead of suppressing the VLA warning, use a fixed-size buffer that is
big enough to receive at least one control message but not so

unix: remove clang compiler warning pragmas (#3989)

Instead of suppressing the VLA warning, use a fixed-size buffer that is
big enough to receive at least one control message but not so big that
IBMi PASE rejects it.

show more ...

unix: use memcpy() instead of type punning (#3990)

Libuv makes no claim to being strict aliasing-clean but type punning
makes me feel unclean so replace it with memcpy().

stream: process more than one write req per loop tick (#3728)

Fixes: https://github.com/libuv/libuv/issues/3668

unix,win: remove UV_HANDLE_SHUTTING flag (#3705)

Replace it with a `uv__is_stream_shutting()` macro that checks the
`shutdown_req` field.

It partially fixes: https://github.com/

unix,win: remove UV_HANDLE_SHUTTING flag (#3705)

Replace it with a `uv__is_stream_shutting()` macro that checks the
`shutdown_req` field.

It partially fixes: https://github.com/libuv/libuv/issues/3663.

show more ...

unix: don't accept() connections in a loop (#3696)

After analysis of many real-world programs I've come to conclude that
accepting in a loop is nearly always suboptimal.

1. 99.9

unix: don't accept() connections in a loop (#3696)

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.

show more ...

stream: uv__drain() always needs to stop POLLOUT (#3675)

Regression caused by 1a91b51976a1adc6972081faa78b6b70022254d3 mistake.

Refs: https://github.com/libuv/libuv/pull/3648
Fi

stream: uv__drain() always needs to stop POLLOUT (#3675)

Regression caused by 1a91b51976a1adc6972081faa78b6b70022254d3 mistake.

Refs: https://github.com/libuv/libuv/pull/3648
Fixes: https://github.com/libuv/libuv/pull/3648/3671

show more ...

unix,stream: optimize uv_shutdown() codepath (#3646)

Once the write queue is empty, we can fire the event immediately,
without needing a lot of syscalls and then waiting for the kernel t

unix,stream: optimize uv_shutdown() codepath (#3646)

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.

show more ...

unix: fix c99 comments (#3667)

Causes compilation errors for people that build libuv with a C89
compiler.

Refs: https://github.com/libuv/libuv/discussions/3666

shutdown,unix: reduce code duplication (#3648)

The UV_ECANCELED codepath had an incorrect comment, and the
implementation was generally less robust (for example, not checking if
`cb`

shutdown,unix: reduce code duplication (#3648)

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.

show more ...

tcp,pipe: fail `bind` or `listen` after `close` (#3641)

Return `UV_EINVAL` in `bind` and `listen` when `handle` is
`UV_HANDLE_CLOSING` or `UV_HANDLE_CLOSED`.

Fixes: https://gith

tcp,pipe: fail `bind` or `listen` after `close` (#3641)

Return `UV_EINVAL` in `bind` and `listen` when `handle` is
`UV_HANDLE_CLOSING` or `UV_HANDLE_CLOSED`.

Fixes: https://github.com/libuv/libuv/issues/3503

show more ...

aix, ibmi: handle server hang when remote sends TCP RST (#3482)

Workaround getsockname() not working for a TCP handle that has
received RST from the remote.

Co-authored-by: Jame

aix, ibmi: handle server hang when remote sends TCP RST (#3482)

Workaround getsockname() not working for a TCP handle that has
received RST from the remote.

Co-authored-by: Jameson Nash <vtjnash@gmail.com>

show more ...

win: fix style nits [NFC] (#3474)

Internal functions usually have a uv__ prefix.

darwin: translate EPROTOTYPE to ECONNRESET (#3413)

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 EPR

darwin: translate EPROTOTYPE to ECONNRESET (#3413)

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

show more ...

darwin: remove EPROTOTYPE error workaround (#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

darwin: remove EPROTOTYPE error workaround (#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

show more ...

stream: permit read after seeing EOF (#3361)

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

stream: permit read after seeing EOF (#3361)

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 ce15b8405e9d01e221f8390475deab4a40d26e38.
Refs: https://github.com/libuv/libuv/pull/3006

show more ...

unix,stream: fix loop hang after uv_shutdown

While most users will likely typically call uv_close in their
uv_shutdown callback, some callers (notable nodejs) do not always do
so. Th

unix,stream: fix loop hang after uv_shutdown

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 80f2f826bf90b84e659321c0b7fd8af419acb85e, 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>

show more ...

stream: introduce uv_try_write2 function

`uv_try_write2(stream, bufs, nbufs, send_handle)` acts like
`uv_try_write()` and extended write function for sending handles over a
pipe like

stream: introduce uv_try_write2 function

`uv_try_write2(stream, bufs, nbufs, send_handle)` acts like
`uv_try_write()` and extended write function for sending handles over a
pipe like `uv_write2`. It always returns `UV_EAGAIN` instead of
`UV_ENOSYS` on Windows so we can easily write cross-platform code
without special treatment.

PR-URL: https://github.com/libuv/libuv/pull/3183
Reviewed-By: Jameson Nash <vtjnash@gmail.com>

show more ...

Re-merge "unix,stream: clear read/write states on close/eof"

This reverts commit 46f36e3df1a666620f6749427f15651cbc4b7001.

PR-URL: https://github.com/libuv/libuv/pull/3006
Refs:

Re-merge "unix,stream: clear read/write states on close/eof"

This reverts commit 46f36e3df1a666620f6749427f15651cbc4b7001.

PR-URL: https://github.com/libuv/libuv/pull/3006
Refs: https://github.com/libuv/libuv/pull/2967
Refs: https://github.com/libuv/libuv/pull/2409
Refs: https://github.com/libuv/libuv/issues/2943
Refs: https://github.com/libuv/libuv/pull/2968
Refs: https://github.com/nodejs/node/pull/36111
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>

show more ...

unix: refactor uv_try_write

This simplifies the code, for better clarify (and performance)!

PR-URL: https://github.com/libuv/libuv/pull/2874
Reviewed-By: Jameson Nash <vtjnash@g

unix: refactor uv_try_write

This simplifies the code, for better clarify (and performance)!

PR-URL: https://github.com/libuv/libuv/pull/2874
Reviewed-By: Jameson Nash <vtjnash@gmail.com>

show more ...

chore: use for(;;) instead of while

In the codebase we have used empty for loop for infinite conditions, so
to bring consistency replaced other occurrences of while in the codebase
w

chore: use for(;;) instead of while

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>

show more ...

unix,win: harmonize uv_read_start() error handling

The behavior of `uv_read_start()` when the handle is closing or already
busy reading wasn't consistent across platforms. Now it is.

unix,win: harmonize uv_read_start() error handling

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>

show more ...