The unix implementation of uv_spawn always starts out with a
uv__handle_init, but the windows implementation sometimes bails out
early before calling uv__handle_init. This means that uv_close on a
failed uv_spawn will always succeed on unix but sometimes fail on
windows.
This commit lifts the initialization of the uv_process_t above all of
the error checking to ensure that uv_close will always work when
uv_spawn returns an error.
The crtdbg.h header was added in c0716b3d, but MinGW does not have this
header present on the system. This commit takes the same approach of
2684f876a and just ignores this header and functionality on MinGW
Every file descriptor opened using libuv should be automatically marked
as CLOEXEC to prevent it from leaking to a child process. Note that
since we are opening fds in a thread pool, there is a possible race
condition between `uv_spawn()` and the `open()` + `uv__cloexec()`. The
rwlock was added to avoid it.
see https://github.com/joyent/node/issues/6905
Changed the order of the member assignments since the thread
may start before the parameters are assigned. This especially
happens when the osx scheduler is very busy.
Changes since version 0.11.17:
* osx: Fix a possible segfault in uv__io_poll (Alex Crichton)
* windows: improved handling of invalid FDs (Alexis Campailla)
* doc: adding ARCHS flag to OS X build command (Nathan Sweet)
* tcp: reveal bind-time errors before listen (Alexis Campailla)
* tcp: uv_tcp_dualstack() (Fedor Indutny)
* linux: relax assumption on /proc/stat parsing (Luca Bruno)
* openbsd: fix obvious bug in uv_cpu_info (Fedor Indutny)
* process: close stdio after dup2'ing it (Fedor Indutny)
* linux: move sscanf() out of the assert() (Trevor Norris)
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.
Changes since version 0.10.22:
* linux: relax assumption on /proc/stat parsing (Luca Bruno)
* openbsd: fix obvious bug in uv_cpu_info (Fedor Indutny)
* process: close stdio after dup2'ing it (Fedor Indutny)
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
