The file itself contains include guards, so don't compile it
conditionally.
PR-URL: https://github.com/libuv/libuv/pull/697
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Libuv would abort() when trying to watch a file descriptor that is
not compatible with epoll-style polling; file descriptors referring
to on-disk files fall into this category.
File descriptors that libuv creates itself are not an issue but
external ones that come in through the uv_poll_init() API are.
Make uv_poll_init() check whether the file descriptor is accepted by
the underlying system call and return an error when it's not.
Fixes: https://github.com/libuv/libuv/issues/658
PR-URL: https://github.com/libuv/libuv/pull/659
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Disabled the filesystem portion of the test as there are known issues
with AIX and its fs. This particular test was failing with a timeout.
PR-URL: https://github.com/libuv/libuv/pull/689
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
If the child process reaches uv_run before the parent has closed the
write end of the pipe the test fails with the following output:
Assertion failed in test/test-pipe-close-stdout-read-stdin.c
on line 86: uv_run(uv_default_loop(), UV_RUN_NOWAIT) == 0
Assertion failed in test/test-pipe-close-stdout-read-stdin.c
on line 97: WIFEXITED(status) && WEXITSTATUS(status) == 0
This is mainly seen on AIX, but does not mean that it can not occur on
linux. This change causes the child process to be blocked until the
write end of the pipe is properly closed. See 'man 7 pipe'[0] for
more detail.
[0]http://linux.die.net/man/7/pipe
PR-URL: https://github.com/libuv/libuv/pull/688
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Tests were failing to link because of undefined snprintf symbol with
VS < 2015 and using shared library.
snprintf is implemented in libuv in src/win/snprintf.c when compiling
with VS < 2015, so this commit add src/win/snprintf.c to test sources
to make snprintf available in tests.
PR-URL: https://github.com/libuv/libuv/pull/678
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Ensure that ltmain.sh gets copied, not symlinked, like we do with
automake artifacts.
PR-URL: https://github.com/libuv/libuv/pull/675
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
uv__fs_buf_iter currently sets req->bufs to NULL after it is done, but
if the operation fails with EINTR then it will be retried, at which
point it expects the bufs to not be NULL, causing a seg fault as in
https://github.com/nodejs/node/issues/4291.
uv__fs_buf_iter should not set req->bufs to NULL if the operation
fails with EINTR.
Also, when it sets req->bufs to NULL, it should set req->nbufs to 0 as
well, so we don't have the messy situation of a positive nbufs with no
actual bufs.
PR-URL: https://github.com/libuv/libuv/pull/661
Reviewed-By: Fedor Indutny <fedor@indutny.com>
uClibc-ng is currently at v1.0.9. The patch corrects the uClibc
version test so that HAVE_IFADDRS_H is defined for uClibc versions
after v0.9.32.
Signed-off-by: Martin Bark <martin@barkynet.com>
PR-URL: https://github.com/libuv/libuv/pull/653
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Trying to acquire a rwlock that the current thread already owns may fail
(not "shall fail") with EDEADLK. Libuv considers that a fatal error and
rightly so in my opinion; it normally means the program contains a logic
error.
The test had indeed logic errors. This commit splits off the UV_EBUSY
return code testing into a separate thread, eliminating the potential
for self-deadlock.
Fixes: https://github.com/libuv/libuv/issues/544
PR-URL: https://github.com/libuv/libuv/pull/649
Reviewed-By: Jeremy Whitlock <jwhitlock@apache.org>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
The following changeset
442b8a5a84 "unix: use QUEUE_MOVE when iterating over lists"
introduced a new assert failure:
`queue_foreach_delete` failed: exit code 6
Output from process `queue_foreach_delete`:
run-tests: src/unix/linux-inotify.c:244: uv_fs_event_stop: Assertion `w != ((void *)0)' failed.
Simplest test case for this:
1. create and start two uv_fs_event_t for the same path;
2. in the callback for the first one, call uv_close() on it;
3. assert/segfault while accessing the second uv_fs_event_t from uv__inotify_read().
PR-URL: https://github.com/libuv/libuv/pull/621
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
The test adds all types of handles, that were known to be affected by
QUEUE_REMOVE()-within-QUEUE_FOREACH() bug, to a loop.
It then calls uv_close() to trigger QUEUE_REMOVE()-within-QUEUE_FOREACH() case
and checks whether a particular QUEUE is corrupted or not.
Restrict the test to Linux only for now as it fails on other platforms
for various reasons.
PR-URL: https://github.com/libuv/libuv/pull/621
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
On Windows the pipe implementation could read more from a stream than
was available and it would create an assertion failure. This change
will make it so we read the minimum of the available data or the length
of the data.
To test this, I took the existing ipc_send_recv_tcp test and updated it
to do two writes and two read on each side of the pipe since that was the
reproduction recipe used by the reporter. This approach reproduced the
issue on Windows and the committed fix resolved the issue.
Fixes: https://github.com/libuv/libuv/issues/505
PR-URL: https://github.com/libuv/libuv/pull/549
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Previous behavior on Windows was to set the path to NULL for removed
and renamed fs events. This was because the path provided by
ReadDirectoryChangesW might (in rare cases) be an 8.3 short name which
could then no longer be converted to a long name after the path had
been removed or renamed. This meant that the user had to detect which
path was actually deleted or renamed and required the user to rescan
the entire watched subtree, taking several seconds or more for large
subtrees.
However, ReadDirectoryChangesW is publicly documented to emit 8.3
short names if the original handle for the changed path was opened
using an 8.3 short name, and libuv may already emit 8.3 short names for
other events if the path cannot be explicitly resolved to a long name.
This commit fixes the path for removed and renamed fs events, and does
not set the path to NULL, even if the path might be an 8.3 short name.
This makes it possible for the user to do a partial scan of the
subtree, restricting the scan to paths which match the long form or 8.3
short name (even if some of these are false positive matches). This
means that deletes and renames can now be detected accurately on
Windows within a few milliseconds.
Fixes: https://github.com/libuv/libuv/issues/634
Refs: https://github.com/libuv/libuv/pull/199
PR-URL: https://github.com/libuv/libuv/pull/639
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Equivalent to realpath(3), returns the full resolved absolute path of a
file or directory.
PR-URL: https://github.com/libuv/libuv/pull/531
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
When `uv_fsevents_t` handle is closed immediately after initializing,
there is a possibility that the `CFRunLoop`'s thread will process both
of these events at the same time. `uv__is_active(handle)` will return
`0`, and the `uv_close()` semaphore will be unblocked, leading
to the use after free in node.js.
See: https://github.com/nodejs/node/issues/4091
PR-URL: https://github.com/libuv/libuv/pull/637
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Remove restriction to Android API level >= 21, now libuv can be used with
Android API level at least 14.
Direct use of getpwuid_r function resulted in linker errors in applications
were built against API level below 21. That function was 'officially'
introduced in Android API level 21, but it exists in libc beginning from API
level at least 14.
So try to get a pointer to getpwuid_r at runtime using dlsym when building
libuv with API level < 21.
PR-URL: https://github.com/libuv/libuv/pull/633
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
'/dev/random' causes 'isatty()' to return 1 on AIX[1]. This causes
an issue where 'dev/tty' is opened (hard coded in
src/unix/tty.c:uv_tty_init). Tried to replace the hardcoded value with
what is returned by 'ttyname()' but on AIX all that is returned is
'/dev/'.
This seems to be a bug with the AIX kernel.
[1]http://goo.gl/wGa7mf
PR-URL: https://github.com/libuv/libuv/pull/624
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
~~~~
test/test-get-loadavg.c:30:14: warning: comparison of array 'avg' not
equal to a null pointer is always true [-Wtautological-pointer-compare]
test/test-getnameinfo.c:76:18: warning: comparison of array 'req.host'
not equal to a null pointer is always true
[-Wtautological-pointer-compare]
test/test-getnameinfo.c:77:18: warning: comparison of array
'req.service' not equal to a null pointer is always true
[-Wtautological-pointer-compare]
~~~~
PR-URL: https://github.com/libuv/libuv/pull/622
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Like the previous commit, but this time for UNIX platforms other than
Linux.
As far as I have been able to establish, dup2 and dup3 never return
EINTR on OS X and FreeBSD. Even if other platforms do return EINTR,
it's probably still better not to retry because it's unspecified
whether the file descriptor has been closed.
Fixes: https://github.com/libuv/libuv/issues/462
PR-URL: https://github.com/libuv/libuv/pull/608
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Retrying seems like a bad idea in a multi-threaded program because the
man page leaves it unspecified whether the file descriptor is closed
after EINTR.
It's probably an academic issue because as far as I have been able to
establish by checking the kernel sources, dup2 and dup3 never actually
return EINTR. For dup3, this appears to have been the case since its
introduction in v2.6.27; for dup2, it goes back to at least v2.6.18.
Fixes: https://github.com/libuv/libuv/issues/462
PR-URL: https://github.com/libuv/libuv/pull/608
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
By default, FreeBSD has net.inet6.ip6.v6only set to 1 (i.e., no dual stack
support). A new function can_ipv6_ipv4_dual is added to check its value and
decide whether `udp_dual_stack` test must be skipped or not.
PR-URL: https://github.com/libuv/libuv/pull/614
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Fixes a compilation problem in some platforms (notably OSX) after
6490c50.
PR-URL: https://github.com/libuv/libuv/pull/618
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Jeremy Whitlock <jwhitlock@apache.org>
uv_(get|set)_process_title is not implemented for AIX. See unix/aix.c
PR-URL: https://github.com/libuv/libuv/pull/616
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Previously, libuv didn't return the correct error code when attempting
to close an invalid file descriptor with `uv_fs_close()`.
PR-URL: https://github.com/libuv/libuv/pull/613
Reviewed-by: Bert Belder <bertbelder@gmail.com>
When duplicating the socket handle being sent the target process
id is defaulted to the current process id. This enables uv_write2
to be used for thread-clustering in addition to process-clustering on
multi-threaded programming languages.
The ipc tests are updated to run in two modes. In the _inproc mode
the echo work is done on a second thread instead of in a second
process.
An internal function int uv_current_pid() is added to the windows
specific code which caches the value of GetCurrentProcessId(). This
means uv_write2 does not call GetCurrentProcessId() every inprocess
send.
Refs: https://github.com/joyent/libuv/issues/926
PR-URL: https://github.com/libuv/libuv/pull/540
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
The pthread_mutex_lock() and pthread_mutex_unlock() calls logically
cannot fail in uv__fs_write() but let's check the return value anyway:
cosmic rays and memory corruption do happen.
PR-URL: https://github.com/libuv/libuv/pull/603
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
I think this makes it clear that the flags can't contain any other
information.
PR-URL: https://github.com/libuv/libuv/pull/592
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
fork and the exec functions are marked prohibited on tvOS and watchOS,
so referencing them causes compile errors.
This adds preprocessor conditionals to avoid calling them for those
targets.
PR-URL: https://github.com/libuv/libuv/pull/580
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
