The comment removed by this commit is no longer relevant, as
the function's return type changed from int to void.
PR-URL: https://github.com/libuv/libuv/pull/804
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Find the real name of the tty using ttyname_r(3) instead of
opening "/dev/tty" which causes trouble if the fd doesn't point to the
controlling terminal.
PR-URL: https://github.com/libuv/libuv/pull/779
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Use `uv__close__nocheckstdio` instead of `close`.
PR-URL: https://github.com/libuv/libuv/pull/798
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
We only need the absolute path to create our .mon file under /aha. So
only duplicate the passed string. This keeps behaviour similar to other
platforms.
Fixes test fs_event_getpath.
PR-URL: https://github.com/libuv/libuv/pull/776
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
uv__makedir_p was not processing all directories in passed string. Now
if a directory already exists (EEXIST) it simply moves onto the next
directory in the provided string.
Fixed bogus assert in uv__ahafs_event.
PR-URL: https://github.com/libuv/libuv/pull/776
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
It can happen that the `parent` end of the `signal_pipe` is given a
STDIO file descriptor, so closing it using `uv__close` fails.
This problem is happening when running the `spawn_closed_process_io`
test in `SmartOS`. The reason being that when creating a socketpair in
`uv__process_init_stdio`, the `Illumos` implementation uses 3 sockets:
one is used as a listener, and the other 2 represent both ends of the
pipe. The listener socket is closed once the pipe is created. In the
test, the listener socket is assigned to the `0` fd, as it is the
first free fd in the system. So the fd `0` remained free after the call
to `socketpair`. Afterwards, when creating the `signal_pipe`, the fd `0`
is being assigned again, so closing it with `uv__close` made the test
fail. This issue is not happening in the other unixes because
`socketpair` doesn't use 3 fd's, but only 2.
To solve the issue, a new `uv__close__nocheckstdio()` function has been
added and used.
PR-URL: https://github.com/libuv/libuv/pull/796
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
wcslen() returns a size_t, not an int.
Add bounds checking to dirlen to avoid undefined if dirlen is 0.
Cache relpath size calculation to replace redundant (- 1 + 1)
expression while still showing workings.
Change uv_relative_path return type to void and remove dead code which
branched on the return value.
PR-URL: https://github.com/libuv/libuv/pull/699
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
When converting an absolute path to a relative path on Windows,
uv_relative_path assumed that the relative path could be no longer than
MAX_PATH characters, and would allocate a buffer of MAX_PATH characters
for the relative path.
However, where a recursive watch is started for a directory using a UNC
path, and where events within that directory occur for pathnames longer
than MAX_PATH, it is possible for the relative path to exceed MAX_PATH
characters and overflow the buffer.
This commit fixes uv_relative_path to allocate a buffer for the exact
number of characters counted in the relative path.
Fixes: https://github.com/libuv/libuv/issues/693
PR-URL: https://github.com/libuv/libuv/pull/699
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
fs__realpath_handle() removes the UNC prefixes \\?\ and \\?\UNC\
from paths returned by GetFinalPathNameByHandle, but doesn't
update the string length before sending it to fs__wide_to_utf8.
Fix that by decrement the correct size from the string length.
PR-URL: https://github.com/libuv/libuv/pull/733
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
uv__open_cloexec returns either the fd or a libuv error, which is -errno
on Unix, not -1.
PR-URL: https://github.com/libuv/libuv/pull/760
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Fedor Indutny <fedor@indutny.com>
When compiling with bionic, st_atime_nsec (and the other nsec members)
canot be found.
In order to compile uv with both NDK and bionic, tv_nsec should be
accessed from st_atimensec (and the others nsec members).
See "Compatibility with glibc" in stat.h from bionic.
Signed-off-by: Robert Chiras <robert.chiras@intel.com>
PR-URL: https://github.com/libuv/libuv/pull/746
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Commit 6798876 ("linux: fix cpu count") switched the /proc/stat parser
to fdopen(). Use fclose() to close the file descriptor to avoid leaking
resources associated with the FILE struct.
PR-URL: https://github.com/libuv/libuv/pull/747
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
'getsockname' does not handle UNIX domain sockets on AIX[1], it does not
fail but simply returns an empty structure with length 0.
If 'getsockname' does not fail (i.e. does not return -1) and the length
is 0 we know, on AIX, that the type is AF_UNIX.
This fixes test pipe_sendmsg.
[1] https://goo.gl/ozqcmS
PR-URL: https://github.com/libuv/libuv/pull/748
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
When libuv is running inside container - eg. lxc container, cpu number
is not obvious. Linux control groups (cgroups) may limit numer of cpus.
As a result of different number cpu cores inside container and
outside container, libuv is crashing.
sysconf(_SC_NPROCESSORS_ONLN) - returns num of host cpus (eg. 32)
`/proc/stat` - sees only cpus limited by cgroups (eg. 4)
When libuv is trying to operate at both numbers and they're different
it's crashing with current test:
run-tests: ../src/unix/linux-core.c:766: read_times: Assertion `num ==
numcpus' failed.
Count the number of cpus based on `/proc/stat` instead.
PR-URL: https://github.com/libuv/libuv/pull/735
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
If an API function returns UV_ENOBUFS make sure we count the terminating
null, which we need space for. In case of success the null byte is not
included in the count, but the buffer *is* null terminated.
PR-URL: https://github.com/libuv/libuv/pull/690
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
libuv has multiple functions which return buffers. Make them consistent
with the following rules: the returned size *does not* include the null
byte, but the buffer *is* null terminated.
There is only one exception to the above: Linux abstract sockets,
because null bytes are not used as string terminators in those.
Refs: https://github.com/libuv/libuv/pull/674
PR-URL: https://github.com/libuv/libuv/pull/690
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
The `__FreeBSD__` macro is not defined by default on OSX, and building
with `-Wundef` will cause a warning to be emitted. This change makes
sure that the macro is only used if defined, removing the warning.
PR-URL: https://github.com/libuv/libuv/pull/710
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
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>
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>
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>
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>
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>
