This error is raised when calling read() or write() on a directory.
A bit of googling turns up some cases where this error can be raised
that are not properly mapped to EISDIR, but are also cases that libuv
doesn't really care about, like the Password Manager API,
GetFirmwareEnvironmentVariable, or CreateTapePartition.
If libuv ever needs to handle these cases, then I suppose that the
ERROR_INVALID_FUNCTION->EISDIR mapping could be done directly in the
fs read() and write() functions, but doing so at this point seems
premature, as it makes the error code mapping a bit more messy.
Fixesjoyent/node#4951
This is a back-port of 4abad23, whichi is supposed to fix
joyent/node#4809.
The private `original_console_mode` field in the uv_tty_t struct has
been renamed, but couldn't be removed because changing the ABI isn't
allowed on stable branches.
In very rare circumstances a uv_read_start() call on a uv_tty_t handle
in raw mode would return -1 but there was no actual failure. This patch
fixes that.
Older versions of GYP would set up the Visual Studio project to link
with these libraries by default, but this was changed in r1584 (see
https://codereview.chromium.org/12256017).
Closes#728
Only report as an error when status != 0.
Stops the platform_output test from being reported as having failed
on Jenkins.
This is a back-port of commit 1821bba from the master branch.
Given UV_TAP_OUTPUT being set, test result output should use TAP formatting
This is a back-port of commit bfe269b from the master branch.
Conflicts:
test/runner-unix.c
Before this commit, it was assumed that connect() on UNIX sockets never
returns EINPROGRESS. It turned out to be a bad assumption: Dave Pacheco
reports sporadic hangups on SmartOS because of that.
It's not clear to me _why_ the Illumos kernel returns that error but
that's inconsequential: whatever the cause, libuv needs to handle it
and now it does.
This is a back-port of commit 3348cd7 from the master branch.
Fixesjoyent/node#4785.
Conflicts:
src/unix/pipe.c
No longer explictly check wheter an IPv6 stack is present when the user
tries to use IPV6 sockets. Instead realy on the operating system
to report the lack of protocol support via appropriate error messages.
This makes uv_tcp_set_socket responsible for setting the UV_HANDLE_IPV6
flag. This fixes a couple of situations where the the fact that a socket
is an IPv6 socket is not taken into account when deciding whether a call
to SetFileCompletionNotificationModes is appropriate.
uv_winsock_init() tries to create an IPv4 socket in order to detect
if the system has any layered service providers (LSPs) installed.
When creating this socket failed it would call uv_fatal_error and exit
with the following message:
socket: (10047) An address incompatible with the requested protocol was used.
This patch fixes that. It also includes some minor style tweaks.
* If GetAdaptersAddresses() failed, it would return UV_OK nonetheless,
but the `adresses` and `count` out parameters would not be set.
* When adapters were enabled or added in between the two
GetAdaptersAddresses() calls, it would fail.
* In case of an out of memory situation, libuv would crash with a fatal
error.
* All interface information is now stored in a single heap-allocated
area.
Obtain the CPU frequency from /proc/cpuinfo because there may not be any
cpufreq info available in /sys. This also means that the reported CPU speed
from now on is the *maximum* speed, not the *actual* speed the CPU runs at.
This change only applies to x86 because ARM and MIPS don't report that
information in /proc/cpuinfo.
Fixes#588.
This is a back-port of commit 775064a from the master branch.
* Use link_settings instead of direct_dependent_settings.
* Fix typo: s/ldlags/ldflags/
Pointed out by a certain R.L. Dahl of San Francisco, CA.
Fixes#618.
Currently, `uv_spawn` will set `environ` to the value of `options.env`, even if
`options.env` is `NULL`. This results in child processes for whom `environ ==
NULL`, which can cause a variety of unexpected issues.
This is a back-port of commit 1d85815 from the master branch.
Guard against the possibility that the queue is emptied while we're iterating
over it. Simple test case:
#include "ngx-queue.h"
#include <assert.h>
int main(void) {
ngx_queue_t h;
ngx_queue_t v[2];
ngx_queue_t* q;
unsigned n = 0;
ngx_queue_init(&h);
ngx_queue_insert_tail(&h, v + 0);
ngx_queue_insert_tail(&h, v + 1);
ngx_queue_foreach(q, &h) {
ngx_queue_remove(v + 0);
ngx_queue_remove(v + 1);
n++;
}
assert(n == 1); // *not* 2
return 0;
}
Fixes#605.
Makes the new process name visible in both `ps` and `ps a`, with the caveat
that `ps` will only print the first 16 characters.
Before this commit, `ps` kept reporting the old process name.
Make uv_cpu_info() understand the ARM and MIPS versions of /proc/cpuinfo,
it only knew how to deal with the x86 version
This commit also fixes a buglet where uv_cpu_info() reported the maximum CPU
frequency instead of the actual CPU frequency. That is, before this commit
`out/Debug/run-tests platform_output | grep speed | sort | uniq -c` on my
system always reported:
8 speed: 3400
Now it reports (for example):
2 speed: 3400
6 speed: 1600
In other words, two CPUs are running at full speed while the others have been
scaled back because they're mostly idle.
This is a back-port of commit 54bfb66 from the master branch.
Fixes#526.
Don't spin in epoll_wait() / kevent() / port_getn() / etc. when we can't
accept() a new connection due to having reached the file descriptor limit.
Pass the error to the connection_cb and let the libuv user deal with it.
Some memory was leaked when the uv_udp_t handle was closed when there were
in-flight send requests with a heap allocated buffer list.
That doesn't happen much in practice. In the common case (writing < 5 buffers),
the buffer list is stored inside the uv_udp_send_t structure, not allocated on
the heap.
uv_update_time does not overwrite the high 32 bits of uv_loop_t.time.
It merely increments it by one when the low 32 bits have wrapped. That
means that `time` needs to be initialized to zero before
uv_update_time() is called for the first time.
uv_fs_poll_t has an embedded uv_timer_t handle that got closed at a time when
the memory of the encapsulating handle might already have been deallocated.
Solve that by moving the poller's state into a structure that is allocated on
the heap and can be freed independently.
