The req->addrinfow field contains the hints in that case, so we must not
free it.
This regression was introduced in f2bb8d3 by yours truly.
PR-URL: https://github.com/libuv/libuv/pull/171
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Linux before kernel 2.6.19 does not support epoll_pwait(). Due to a
logic error in commit 2daf944 ("unix: add flag for blocking SIGPROF
during poll"), the fallback path for ENOSYS was not taken.
This commit also adds epoll_pwait() emulation using pthread_sigmask().
The block/unblock operations are not atomic but that is fine for our
particular use case, to wit, sleep through SIGPROF signals.
PR-URL: https://github.com/libuv/libuv/pull/162
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
libuv requires that the socket/fd is in non-blocking mode, so do it
internally so the user doesn't need to write platform specific code to
do so.
This also makes the API consistent with uv_{tcp,udp,pipe}_open, since
it's not required to pass the fd in non-blocking mode there either.
PR-URL: https://github.com/libuv/libuv/pull/136
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
The contract specifies that the file descriptor should already be in
non-blocking mode before passing it to libuv.
However, node users don't really have an opportunity to do so, never
mind the fact that the call to uv_pipe_open() or uv_tcp_open() is an
implementation detail that most users won't be aware of.
Let's be nice and set the non-blocking flag explicitly. It's a cheap
operation anyway.
Fixes: https://github.com/libuv/libuv/issues/124
PR: https://github.com/libuv/libuv/pull/134
Reviewed-by: Saúl Ibarra Corretgé <saghul@gmail.com>
The mode argument is an enum now and the signedness of an enum is
implementation-defined when it doesn't have negative members.
Cast it to int in the comparison to tty->mode because the latter is
still an int.
PR: https://github.com/libuv/libuv/pull/134
Reviewed-by: Saúl Ibarra Corretgé <saghul@gmail.com>
All windows console writes are synchronous anyway, so there's no reason
for uv_try_write() to do nothing.
PR: https://github.com/libuv/libuv/pull/127
Reviewed-by: Saúl Ibarra Corretgé <saghul@gmail.com>
I'm not 100% sure whether the behavior of readlink() with size=0 is
well-defined on Solaris; it can return either 0 or fail with EINVAL.
POSIX is not explicit about the mandated behavior.
This commit adds a little caution and makes it skip the readlink()
call when size=1 and simply writes the terminating zero byte.
PR-URL: https://github.com/libuv/libuv/pull/104
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
uv_exepath() should write as much as possible to the output buffer.
In the case of size=1, skip the call to readlink() because it will
fail with EINVAL; just write the terminating zero byte.
PR-URL: https://github.com/libuv/libuv/pull/104
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Write as much of the path as possible to the output buffer. Before this
commit, passing in a buffer that was too small to hold the result failed
with a UV_EINVAL error.
PR-URL: https://github.com/libuv/libuv/pull/104
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Passing a buffer that was too small to hold the result made it fail
with UV_EPERM because the -1 status code from _NSGetExecutablePath()
was returned unmodified to the caller.
This commit rewrites uv_exepath() to:
1. Not allocate heap memory, and
2. Not clobber the result buffer on error, and
3. Handle _NSGetExecutablePath()'s and realpath()'s idiosyncracies, and
4. Store as much of the path in the output buffer as possible, don't
fail with an error. Makes it behave the same as other platforms.
The result is always zero-terminated.
Fixes: https://github.com/libuv/libuv/issues/103
PR-URL: https://github.com/libuv/libuv/pull/104
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Make the behavior of a call to uv_exepath() with a size argument of zero
consistent with the Windows implementation where it returns UV_EINVAL.
PR-URL: https://github.com/libuv/libuv/pull/104
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
The fix from commit 269ff0be is wrong in that it sniffs system headers
to determine if preadv() and pwrite() are supported.
It breaks the fs_write_multiple_bufs test on one of my ARM systems;
its glibc has preadv() and pwritev() wrappers but its kernel has no
support for the corresponding system calls.
Simply try the system call and fall back to a normal read or write
loop if not supported. Move the no_preadv and no_pwritev variables
around to squelch two -Wpedantic warnings about mixing declarations
with code.
PR-URL: https://github.com/libuv/libuv/pull/90
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Using a static thread local variable to store the thread handle causes
crashes on Windows XP/2003 when libuv is loaded as a dynamic library.
With this patch, a TLS slot is allocated dynamically.
PR-URL: https://github.com/libuv/libuv/pull/82
Reviewed-By: Bert Belder <bertbelder@gmail.com>
This reverts commit a9e95a33bc.
This seems to cause regressions in the test suite when IPv6 is disabled.
As optimizations go, it's a very minor one so let's not spend too much
effort trying to track down the cause of the regressions but revert the
change before it makes its way into a release.
PR-URL: https://github.com/libuv/libuv/pull/92
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Only call setsockopt() when the initial bind() fails with EADDRINUSE,
then retry. Saves a system call in what is normally the common case.
PR-URL: https://github.com/libuv/libuv/pull/88
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Introduce a uv_tty_mode_t enum for uv_tty_set_mode(), with backward
compatible values. Add a new mode UV_TTY_MODE_IO, which uses
cfmakeraw() internally.
PR-URL: https://github.com/libuv/libuv/pull/86
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Revisit the fix from commit b705b53. The problem with using sigset_t
and _NSIG is that the size of sigset_t and the value of _NSIG depend
on what headers libuv picks up first, <signal.h> or <asm/signal.h>.
With the former, sizeof(sigset_t) = 128; with the latter, it's 8.
Simply sidestep the issue by calculating the signal mask as a 64 bits
integer, without using sigset_t or _NSIG.
PR-URL: https://github.com/libuv/libuv/pull/83
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
If pending I/O callbacks were ran before polling, do a zero timeout
poll.
PR-URL: https://github.com/libuv/libuv/pull/58
Reviewed-By: Bert Belder <bertbelder@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
The modes are not meant to be combined, and doing so may hide problems
in the future.
PR-URL: https://github.com/libuv/libuv/pull/58
Reviewed-By: Bert Belder <bertbelder@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
This aligns the behavior with the Windows implementation.
PR-URL: https://github.com/libuv/libuv/pull/63
Reviewed-By: Bert Belder <bertbelder@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
FormatMessage can fail, e.g. with ERROR_MUI_FILE_NOT_FOUND. In this case
no error message was set and uv_dlerror wrongly returned "no error".
With this patch the fallback error message "error: <errorno>" is
generated when FormatMessage fails.
PR-URL: https://github.com/libuv/libuv/pull/59
Reviewed-By: Bert Belder <bertbelder@gmail.com>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
When the user closes an uv_poll_t handle, there may still be an
outstanding AFD_POLL request. Libuv can't cancel this AFD_POLL request
directly, so it has to submit another which makes the the previous
poll request return.
Libuv completely forgets about the "canceling" AFD_POLL request, but
at some point in time it may complete and store its result somewhere in
memory.
Without this patch the result of the canceling poll request is written
somewhere on the stack, which sometimes causes stack corruption. This
patch ensures that the result is written to some static scratch space
where it can do no harm.
PR-URL: https://github.com/libuv/libuv/pull/49
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Marc Schlaich <marc.schlaich@gmail.com>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
The offending patch doesn't completely fix the issue, it just trades
stack corruption for heap corruption which is less likely.
In addition there is a much simpler solution for this problem.
This reverts commit cd894521dd.
PR-URL: https://github.com/libuv/libuv/pull/49
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Marc Schlaich <marc.schlaich@gmail.com>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
