When building using gyp and BUILDTYPE=Release using clang 3.4 received
this warning:
../src/unix/linux-core.c:640:34: warning: variable 'n' is uninitialized
for (len = sizeof("cpu0"); n /= 10; len++);
^
Initializing n = 0 silences this build warning.
Thus allow passing the same file descriptor as the source of multiple
stdios.
Committed with the help and code parts from:
* Sam Roberts <sam@strongloop.com>
fix#1074
CPU entries in /proc/stat are not guaranteed to be monotonically
increasing, asserting on this assumption can break in cases such
as the UltraSparc II machine shown in #1080.
Signed-off-by: Luca Bruno <lucab@debian.org>
Changed uv_tcp_duplicate_socket to reveal any bind-time errors
before calling listen().
This fix is 100% windows specific.
It helps fix Node.js unite test test-cluster-bind-twice on Windows.
If passed and invalid FD, _get_osfhandle() sets an error code
through errno, not _doserrno. Hence we need to use
SET_REQ_WIN32_ERROR insted of SET_REQ_RESULT.
In debug builds, _get_osfhandle() also raises a superfluous
assert. I implemented a wrapper that disables all asserts
around the call to _get_osfhandle().
This fixes node.js unit tests test-fs-read-stream.js and
test-listen-fd-ebadf.js.
Changes since version 0.11.16:
* stream: allow multiple buffers for uv_try_write (Fedor Indutny)
* unix: fix a possible memory leak in uv_fs_readdir (Alex Crichton)
* unix, windows: add uv_loop_alive() function (Sam Roberts)
* windows: avoid assertion failure when pipe server is closed (Bert
Belder)
* osx: Fix a possible segfault in uv__io_poll (Alex Crichton)
* stream: fix uv__stream_osx_select (Fedor Indutny)
uv__stream_osx_interrupt_select was only defined on OS X, but is used
elsewhere on all platforms. The intention was to implement it as a
no-op on other platforms, but the entire definition was inside
"#ifdef __APPLE__", so this didn't actually work.
Fix: move it above the #ifdef.
Relying on `readable`/`writable` when polling will lead to the select
thread spinning in the loop and calling `uv_async_send()`, because
stream may never become not `readable`/`writable`.
We should rely on `uv__io_active()` instead and interruprt select thread
every time it changes.
If multiple handles arrive to the IPC pipe at the same time (happens on
some platforms), libuv will queue them internally, and call `read2_cb`
multiple times with a null-buffer and proper `handle_type`.
In our build infrastructure, I've seen a lot of segfaults recently that
were all only happening on OSX. Upon inspecting the coredumps, it
appearded that all segfaults happened at the same instruction, and upon
translating the assembly back to the source, I found that an array could
be indexed with a -1 index before the index was checked to be not -1.
As concrete evidence, here is the situation that I found caused the
segfault. The instruction in question along with the relevant register
values was:
mov (%r8,%r15,8),%r12
r8 = 0x7fb0ba800000
r15 = 0xffffffffffffffff
r8 + r15 * 8 == 0x7fb0ba7ffff8
It appears that the base of loop->watchers was page aligned, and by
going back one word I guess that the page wasn't mapped, causing our
segfaults.
In our build infrastructure, I've seen a lot of segfaults recently that
were all only happening on OSX. Upon inspecting the coredumps, it
appearded that all segfaults happened at the same instruction, and upon
translating the assembly back to the source, I found that an array could
be indexed with a -1 index before the index was checked to be not -1.
As concrete evidence, here is the situation that I found caused the
segfault. The instruction in question along with the relevant register
values was:
mov (%r8,%r15,8),%r12
r8 = 0x7fb0ba800000
r15 = 0xffffffffffffffff
r8 + r15 * 8 == 0x7fb0ba7ffff8
It appears that the base of loop->watchers was page aligned, and by
going back one word I guess that the page wasn't mapped, causing our
segfaults.
When a pipe server is closed, all pending accept requests and their
associated HANDLEs are closed to force windows to cancel the
ConnectNamedPipe IRP. The returned request has the `pipeHandle` field
set to INVALID_HANDLE_VALUE, which trips an assert in
uv_pipe_process_accept_req. This patch fixes that.
Useful to know when the the event loop is empty, this can't be done with
uv_run() without possibly blocking, or running some events (which might
empty the event loop as a side-effect).
Some scandir implementations allocate the dirent struct even if the
directory is empty, so if `scandir` returns 0 there may still be memory
that needs to get deallocated. I have altered uv__fs_readdir to go to
the "deallocation exit area" when 0 files are found in the directory
and continue to return early on a return value of -1.
I went to add a test for this functionality, but it appears that one
already exists (reading an empty directory), so I imagine that the
valgrind builds must only be happening on linux instead of OSX as well?
I have confirmed manually that a program without this fix will
infinitely leak memory, and with this fix the memory usage stays
constant.
`uv_try_write(stream, buf, size)` acts like `uv_write()`,
but without queueing actual write until UV_POLLOUT (or IOCP completion).
This is useful for doing writes using on-stack `uv_write_t` requests.
fix#1025
We weren't always translating system errors for in uv_spawn.
This is half a fix for node's unit test
test-child-process-cwd.js on win.
The rest will go into node lib.
It also fixes test-child-process-exec-error
Large performance counter frequency values would cause overflows, even
when 64-bit integers were used to do the multiplication with NANOSEC.
Fix this by using floating point math instead.
Fixes#850
First of all, a bit of explanation of what happens there:
1. FSEvents emits absolute paths to changed files or directories
2. We cut off the first part of such paths, which is equal to handle's
real path ('/dir/subdir/subsubdir`, without trailing slash)
3. Then, if we are running in non-recursive mode, we discard paths that
have slashes ('/') as a non-first character in them
Commit 3d2c820 back-ports a patch from the master branch that disables
the use of SO_REUSEPORT on Linux for reasons mentioned in the commit
log.
Unfortunately, the back-port was incomplete; another setsockopt() call
site in src/unix/udp.c was overlooked. This commit rectifies that.
Hat tip to Luca Bruno for helping troubleshoot the issue.
Fix a bug that was introduced in commit 3ee4d3f ("unix, windows:
return error codes directly") and add a regression test for good
measure.
Hat tip to Fedor for pointing out the issue.
Fixes#1007.
Print the error message rather than just the errno. The fact that the
errno is 24 is only informative to people that have their operating
system's error codes memorized.
