The code made an implicit assumption that the 'len` variable passed
to the sendfile(2) syscall is not modified by the operating system
in case of an error other than EAGAIN or EINTR.
The man page leaves this unspecified on FreeBSD, DragonFly and
Darwin, so better check the error code which returns a valid
value in `len` explicitly (only EAGAIN and EINTR).
This fixes the test case for sendfile on DragonFly.
PR-URL: https://github.com/libuv/libuv/pull/466
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
\r is a single carriage return without line feed on all platforms,
including Windows.
PR-URL: https://github.com/libuv/libuv/pull/472
Reviewed-By: Bert Belder <bertbelder@gmail.com>
Commit 0f1bdb6 ("threadpool: send signal only when queue is empty")
introduces a regression where work is not evenly distributed across
the thread pool because the work queue's condition variable is only
signalled when the queue is empty, even when there are waiting workers.
It doesn't turn into outright deadlock because there is always
at least one thread making forward progress but it does degrade
throughput, sometimes massively so.
Signalling whenever there are waiting workers fixes the throughput
issue while still keeping the number of uv_cond_signal() calls low,
which was the motivation for commit 0f1bdb6.
Fixes: https://github.com/libuv/libuv/pull/490
Fixes: https://github.com/libuv/libuv/issues/492
PR-URL: https://github.com/libuv/libuv/pull/493
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
It's an error to do so, so just ignore it. The test would cause an
invalid memory access if the fix is undone.
PR-URL: https://github.com/libuv/libuv/pull/488
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
On Windows we create multiple pipe handles (system handles) which are
attached to pending accept requests. Each of these will take turns in
replacing the reference in handle->handle, so make sure we allow for
that **only** for pipe servers.
PR-URL: https://github.com/libuv/libuv/pull/488
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
On pipe servers handle->handle takes turns between the different server
handles, so after closing all of them just reset the dandling reference.
PR-URL: https://github.com/libuv/libuv/pull/488
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Makes uv_loop_init return an error code instead of aborting.
Currently uv_loop_init aborts if there are insufficient resources
available. As a user I want to be able to check the return code from
uv_loop_init and decide how I respond rather than having my process die.
PR-URL: https://github.com/libuv/libuv/pull/405
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
At least on OS X 10.10 "Yosemite", an EPROTOTYPE can occur
when trying to write to a socket that is shutting down.
By retrying the write after EPROTOTYPE, we correctly get EPIPE.
PR-URL: https://github.com/libuv/libuv/pull/482
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Make uv_err_name() and uv_strerror() return a dynamically allocated
string when the error code is not recognized.
It leaks a few bytes of memory but that can't be helped. Asserting
and aborting is, in my opinion, much less helpful.
Fixes: https://github.com/nodejs/node/issues/63
PR-URL: https://github.com/libuv/libuv/pull/467
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
For synchronous file operation requests (ones without a callback), there
is no need to make a copy of the arguments because they don't outlive
the scope of the function call.
PR-URL: https://github.com/libuv/libuv/pull/479
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
The parentheses are unnecessary because what they wrap are not macro
arguments but function arguments that aren't evaluated by the macro.
PR-URL: https://github.com/libuv/libuv/pull/479
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
This allows writing and reading any amount of buffers,
regardless of what IOV_MAX may be defined as.
It also moves the IOV_MAX test from stream to core.
This is based on the excellent work of @bwijen in #269.
Refs: https://github.com/libuv/libuv/pull/269
PR-URL: https://github.com/libuv/libuv/pull/448
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
uv_exepath() was not behaving correctly on AIX when the process was
invoked with a relative path.
The logic has been reworked to:
1) Use getargs() to retrieve the process arguments
2) Use realpath() to handle absolute and relative paths and
symbolic links
3) Check that a match when searching the PATH is executable (if
not search will continue)
PR-URL: https://github.com/libuv/libuv/pull/464
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Add new UV__POLLRDHUP event to be emitted when EPOLLRDHUP(in Linux) or
EV_EOF(in BSD / OSX) is detected and only if UV_READABLE is set.
When a read returns ECONNRESET after a UV__POLLRDHUP event, emit EOF instead
of the error.
Add tcp-squelch-connreset test. Not to be run on Windows as it returns
ECONNRESET error.
Fixes in test-poll and test-tcp-open so they pass after these changes.
PR-URL: https://github.com/libuv/libuv/pull/403
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Use the console text color set by the user rather than assuming the
Windows default (white foreground on black background).
PR-URL: https://github.com/libuv/libuv/pull/431
Reviewed-By: Bert Belder <bertbelder@gmail.com>
UV_HANDLE_CONNECTED was defined, but never used anywhere - outside this if
condition inside uv__stdio_create. So this test can't be true.
UV_HANDLE_CONNECTION was meant.
A test was also added verifying the behaviour.
PR-URL: https://github.com/libuv/libuv/pull/404
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Silences the following runtime errors when compiling UBSan:
../src/unix/linux-core.c:181:9: runtime error: member access within null
pointer of type 'uv__io_t' (aka 'struct uv__io_s')
../src/unix/process.c:67:15: runtime error: member access within null
pointer of type 'uv_process_t' (aka 'struct uv_process_s')
../src/unix/process.c:91:15: runtime error: member access within null
pointer of type 'uv_process_t' (aka 'struct uv_process_s')
...
PR-URL: https://github.com/libuv/libuv/pull/422
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Once we are past uv__stream_init, the handle has been added to
loop->handle_queue, it needs to be undone in case of failure.
PR-URL: https://github.com/libuv/libuv/pull/414
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
OSX, other BSDs and SunoS fail with EAFNOSUPPORT when binding a socket created
with AF_INET to an AF_INET6 address or vice versa.
PR-URL: https://github.com/libuv/libuv/pull/407
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Introduce two new APIs:
int uv_tcp_init_ex(uv_loop_t*, uv_tcp_t* handle, int flags)
int uv_udp_init_ex(uv_loop_t*, uv_udp_t* handle, int flags)
The lower 8 bits of the flags field are used for the socket domain.
AF_INET, AF_INET6 and AF_UNSPEC are supported. If AF_UNSPEC is specified
the socket is created lazily, just like uv_{tcp,udp}_init.
Some Windows notes:
getsockname fails with WSAEINVAL if the socket is not bound. This could
potentially be improved by detecting the socket family and filling
the sockaddr_in/6 struct manually.
bind returns WSAEFAULT if we try to bind a socket to the wrong family.
Unix returns EINVAL.
PR-URL: https://github.com/libuv/libuv/pull/400
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
This fixes a bug I have noticed with nodejs:
> cat test.js
console.log(process.execPath);
> node test.js (on DragonFly)
node test.js
> node test.js (on Linux)
node
PR-URL: https://github.com/libuv/libuv/pull/399
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Use the same code path as FreeBSD does.
PR-URL: https://github.com/libuv/libuv/pull/399
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
As stated in malloc's docs[1], the malloc.h is required for using the
malloc function, and from malloc.h's source code (which can be found
under installed VS), malloc is defined as a macro that has different
behaviors under different configurations.
So using malloc without including malloc.h is very dangerous, for
certain build configurations crashes can happen when writing to memory
allocated by malloc.
[1]: https://msdn.microsoft.com/en-us/library/6ewkz86d.aspx
PR-URL: https://github.com/libuv/libuv/pull/395
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Bert Belder <bertbelder@gmail.com>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
When a Windows handle was opened from a CRT fd, it needs to be closed
with `close()` instead of `CloseHandle()`.
PR-URL: https://github.com/libuv/libuv/pull/396
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
_get_osfhandle() may throw if it's used to convert a non-open file
descriptor to a Windows HANDLE. Use the safe uv__get_osfhandle instead.
PR-URL: https://github.com/libuv/libuv/pull/396
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
When a Windows handle was opened from a CRT fd, it needs to be closed
with `close()` instead of `CloseHandle()`.
PR-URL: https://github.com/libuv/libuv/pull/396
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Certain types of streams may be opened from a CRT file descriptor (as
opposed to a Windows HANDLE). In order to close the file descriptor
later, libuv must store the file descriptor used to open the stream.
PR-URL: https://github.com/libuv/libuv/pull/396
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Some systems, FreeBSD for example, may return negative values.
sysconf() returns a long, which was being converted to a size_t.
This conversion lead to large allocations, and subsequent out of
memory failures. This commit checks the long value returned by
sysconf() properly, and uses a default value of 4096 if a negative
number is returned.
PR-URL: https://github.com/libuv/libuv/pull/389
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
src/win/util.c: In function 'uv_os_homedir':
src/win/util.c:1189:46: warning: passing argument 3 of 'GetUserProfileDirectoryW' from incompatible pointer type
if (!GetUserProfileDirectoryW(token, path, &bufsize)) {
^
In file included from src/win/util.c:39:0:
C:/buildtools/vendor/mingw64/x86_64-w64-mingw32/include/userenv.h:52:29: note: expected 'LPDWORD' but argument is of type 'size_t *'
USERENVAPI WINBOOL WINAPI GetUserProfileDirectoryW(HANDLE hToken,LPWSTR lpProfileDir,LPDWORD lpcchSize);
^
PR-URL: https://github.com/libuv/libuv/pull/388
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
The previous Windows implementation used SHGetKnownFolderPath(),
which is only supported on Vista and up. This commit switches to
GetUserProfileDirectoryW(), which returns the same information,
but is supported back to Windows 2000, and is not deprecated.
PR-URL: https://github.com/libuv/libuv/pull/375
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
