Treat both the base being NULL or the length being 0 as ENOBUFS.
PR-URL: https://github.com/libuv/libuv/pull/997
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
When Windows resumes after sleep GetQueuedCompletionStatus timeout is
not updated. This commit adds a method for signaling all loops to
wake up and update their timers.
Fixes: https://github.com/nodejs/node/issues/6763
PR-URL: https://github.com/libuv/libuv/pull/962
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
This reverts commit 7892bd6f76.
The reasoning for the original patch was flawed. On x86 systems
_InterlockedOr intrinsic must be used. MinGW also exposes the problem,
so reverting this gets rid of a warning.
PR-URL: https://github.com/libuv/libuv/pull/990
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
- Use atomic ops both to set and reset async_sent flag
- Remove the MinGW atomic ops, since Windows intrinsics are supported
- Remone thread-unsafe checks from uv_async_send
According to MSDN there are no alignment requirements. We could use
InterlockedExchange8, but that's only available on Windows >= 8.
This change is intended to make uv_async_send more resilient. It has to
be thread-safe, and that means that the handle could just have been
closed when uv_async_send was called. This case was previously not
handles (there is an inherent race condition). The new model is inspired
by the one used on the Unix side, which uses a single fd (or overlapped
in this case) to wakeup the loop and then process all pending async
handles. This makes handling those edge cases a lot simpler: when the
handle is closed it's removed from the handle queue, and then it's not
processed at all.
As a result of this change, async benchmarks work on Windows where they
previously failed with assertions.
PR-URL: https://github.com/libuv/libuv/pull/980
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
This code has been disabled since 2011, I guess we're ok without it.
PR-URL: https://github.com/libuv/libuv/pull/971
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
On OS X, special files like /dev/null and /dev/tty don't work with
kqueue. Libuv falls back to select() in that case but the initial
probe didn't handle EINTR.
Introduced in August 2012 in commit 731adaca ("unix: use select()
for specific fds on OS X"), this bug was only ten days away from
celebrating its fourth birthday.
PR-URL: https://github.com/libuv/libuv/pull/979
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
MinGW (from mingw.org) is really old, so stop pretending we support it.
Just support MinGW-w64, which works also works with 32bit Windows,
despite it's misleading name.
PR-URL: https://github.com/libuv/libuv/pull/969
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
It's now present on all supported macOS and iOS versions.
PR-URL: https://github.com/libuv/libuv/pull/966
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Fedor Indutny <fedor@indutny.com>
Libuv leaves loop->data unchanged in uv_loop_init() and uv_loop_done()
on Windows but it clobbered it on UNIX platforms. This commit fixes
that inconsistency.
PR-URL: https://github.com/libuv/libuv/pull/951
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
We not only check the return value, but also check the errno != 0.
Because in rare cases connect() will return -1 but the errno
is 0 (for example, on Android 4.3, OnePlus phone A0001_12_150227)
and actually the tcp three-way handshake is completed.
PR-URL: https://github.com/libuv/libuv/pull/936
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Imran Iqbal <imran@imraniqbal.org>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
This commit causes uv_get_process_title() to:
- return EINVAL if the buffer is null or size is 0
- return ENOBUFS if the title is too big for the buffer
- null terminate the buffer on success
Fixes: https://github.com/libuv/libuv/issues/315
PR-URL: https://github.com/libuv/libuv/pull/928
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
It was pointed out[0] that libuv could effectively enter an infinite
loop (but not a busy loop) under certain conditions when polling for
events:
1. When the architecture is 32 bits, and
2. When timeout > 0, i.e., finite, and
3. When timeout > max_safe_timeout (~30 minutes), and
4. When epoll_wait(timeout) returns 0, then
5. timeout was not properly updated on the next call to epoll_wait().
Inspection of the code uncovered a secondary bug where under a similar
set of circumstances the timeout could drift when the epoll_wait()
system call returned late.
[0] https://github.com/libuv/libuv/pull/354#discussion_r67837112
PR-URL: https://github.com/libuv/libuv/pull/922
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
This commit causes Window file watching events to compare the
entire file path when filtering events. This fixes a bug where
incomplete path comparisons would cause invalid events to be
raised.
Refs: https://github.com/libuv/libuv/pull/682
PR-URL: https://github.com/libuv/libuv/pull/924
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Don't call uv__to_stat() when the stat/fstat/lstat system call fails;
the stack-allocated buffer contains only garbage in that case.
Not a very serious bug it's technically undefined behavior and it made
valgrind squawk.
Introduced in commit 499c7976 ("unix, windows: nanosecond resolution
for uv_fs_[fl]stat").
PR-URL: https://github.com/libuv/libuv/pull/921
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
If getifaddrs() returns an all zero ifa_addr field, then use ARP to
set the phys_addr field of the uv_interface_address_t on the sunos
platform.
PR-URL: https://github.com/libuv/libuv/pull/907
Reviewed-By: Imran Iqbal <imran@imraniqbal.org>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
`unsigned long` is not guaranteed to be 8 bytes long. This prevents
overflow errors from occurring as seen in issue #913
Fixes: https://github.com/libuv/libuv/issues/913
PR-URL: https://github.com/libuv/libuv/pull/914
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
This fixes test-stdio-over-pipes and test-pipe-sendmsg test cases.
~~~~
Assertion failed in test/test-stdio-over-pipes.c on line 56: term_signal == 0
Assertion failed in test/test-pipe-sendmsg.c on line 86: pending == UV_NAMED_PIPE
~~~~
This fixes a longstanding issue with nodejs on DragonFly, which was
triggered whenever spawning a process and pipes were involed.
PR-URL: https://github.com/libuv/libuv/pull/884
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Imran Iqbal <imran@imraniqbal.org>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
The _SC_PHYS_PAGES and _SC_AVPHYS_PAGES are not POSIX sysconf values, so
the standart C libraries have no obligation to support it, even on
Linux. Use the Linux sysinfo() system call instead.
PR-URL: https://github.com/libuv/libuv/pull/901
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
It's just an indicator that the operation will happen later, so return
success.
PR-URL: https://github.com/libuv/libuv/pull/892
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
When we send VK_RETURN to make ReadConsole return, a spurious new line
is echoed to the screen. This is pretty visible in Node.js, since it
calls uv_tty_read_start() and uv_tty_read_stop() in rapid succession
during startup.
With this change, we save the screen state just before sending
VK_RETURN, and restore the cursor position as soon as ReadConsole
returns.
PR-URL: https://github.com/libuv/libuv/pull/866
Reviewed-by: Bert Belder <bertbelder@gmail.com>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
