Problem: registering two uv_fs_event_t watchers for the same path, then closing
them, caused a segmentation fault. While active, the watchers didn't work right
either, only one would receive events.
Cause: each watcher has a wd (watch descriptor) that's used as its key in a
binary tree. When you call inotify_watch_add() twice with the same path, the
second call doesn't return a new wd - it returns the existing one. That in turn
resulted in the first handle getting ousted from the binary tree, leaving
dangling pointers.
This commit addresses that by storing the watchers in a queue and storing the
queue in the binary tree instead of storing the watchers directly in the tree.
Fixesjoyent/node#3789.
uv_set_process_title() was susceptible to a format string vulnerability:
$ node -e 'process.title = Array(42).join("%s")'
Segmentation fault: 11 (core dumped)
The fix is trivial - call setproctitle("%s", s) instead of setproctitle(s) -
but valgrind complains loudly about reads from and writes to uninitialized
memory in libc. It's not a libuv bug because the test case below triggers the
same warnings:
#include <sys/types.h>
#include <unistd.h>
int main(void)
{
setproctitle("%s", "test");
return 0;
}
That's why this commit replaces setproctitle() with sysctl(KERN_PROC_ARGS).
This commit reapplies commit a9f6f06, which got reverted in 69a6afe. The revert
turned out to be unnecessary.
It's making node.js crash when run as root. Backtrace:
(gdb) bt
#0 0x00007fff856e3ff9 in __findenv ()
#1 0x00007fff856e404c in getenv ()
#2 0x000000010004c850 in loop_init (loop=0x10045a792, flags=8) at ev.c:1707
#3 0x000000010004cb3b in ev_backend [inlined] () at /Users/tjfontaine/Development/node/deps/uv/src/unix/ev/ev.c:2090
#4 0x000000010004cb3b in ev_default_loop (flags=1606417108) at ev.c:2092
#5 0x000000010004e5c6 in uv__loop_init (loop=0x10066e330, default_loop=1) at loop.c:52
#6 0x0000000100044367 in uv_default_loop () at core.c:196
#7 0x0000000100004625 in node::Init (argc=1606417456, argv=0x100b0f490) at node.cc:2761
#8 0x000000010000797d in node::Start (argc=1606417600, argv=0x0) at node.cc:2888
#9 0x0000000100000ca4 in start ()
This reverts commits:
b49d6f7 unix: fix uv_set_process_title()
a9f6f06 unix: fix format string vulnerability in freebsd.c
a87abc7 unix: avoid buffer overflow in proctitle.c
dc97d44 unix: move uv_set_process_title() to proctitle.c
Use strncpy() to set the process title, it pads the remainder with nul bytes.
Avoids garbage output on systems where `ps aux` prints the entire proctitle
buffer, not just the characters up to the first '\0'.
Fixesjoyent/node#3726.
uv_set_process_title() was susceptible to a format string vulnerability:
$ node -e 'process.title = Array(42).join("%s")'
Segmentation fault: 11 (core dumped)
The fix is trivial - call setproctitle("%s", s) instead of setproctitle(s) -
but valgrind complains loudly about reads from and writes to uninitialized
memory in libc. It's not a libuv bug because the test case below triggers the
same warnings:
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <unistd.h>
int main(void)
{
setproctitle("%s", "test");
return 0;
}
That's why this commit replaces setproctitle() with sysctl(KERN_PROC_ARGS).
Use hijacking argv array to change process' title. It seems to be working fine
on almost every platform (at least it should not break anything as it's used in
nginx in a similar way).
This is a back-port of commit e1320757 from the master branch.
Newer versions of gyp do not support files with the same basenames (example:
core.c and linux/core.c).
The nominal reason is consistency across build systems. Apparently, msbuild
doesn't support it either.
Somewhere, someplace, baby Jesus cries sad little tears...
Fixes#464.
Use atomic compare-and-swap to detect if we've been preempted by another thread
and therefore can avoid making the expensive write() syscall.
Speeds up the heavily contended case by about 1-2% and has little if any impact
on the non-contended case. I wasn't able to measure the difference at any rate.
Don't start reading immediately after connecting. If the server sends a message
and the client hasn't called uv_read_start() yet, the event loop will busy loop
because the pending message keeps waking it up.
Don't make the event loop spin when connect() returns EINPROGRESS.
Test case:
#include "uv.h"
static void connect_cb(uv_connect_t* req, int status) {
// ...
}
int main() {
uv_tcp_t handle;
uv_connect_t req;
struct sockaddr_in addr;
addr = uv_ip4_addr("8.8.8.8", 1234); // unreachable
uv_tcp_init(uv_default_loop(), &handle);
uv_tcp_connect(&req, (uv_stream_t*)&handle, addr, connect_cb);
uv_run(uv_default_loop()); // busy loops until connection times out
return 0;
}
After EINPROGRESS, there are zero active handles and one active request. That
in turn makes uv__poll_timeout() believe that it should merely poll, not block,
in epoll() / kqueue() / port_getn().
Sidestep that by artificially starting the handle on connect() and stopping it
again once the TCP handshake completes / is rejected / times out.
It's a slightly hacky approach because I don't want to change the ABI of the
stable branch. I'll address it properly in the master branch.
Incidentally fixes a rather obscure bug where uv_tcp_connect() reconnected
and leaked a file descriptor when the handle was already busy connecting,
handle->fd was zero (unlikely) and uv_tcp_connect() got called again.
accept4() piggybacks on the socketcall() on i386. socketcall() has the flaw
that it returns EINVAL instead of ENOSYS when the operation is not supported.
The problem is that accept4() also returns EINVAL when its flag argument is
invalid.
Try to discern between the two failure cases to the best of our abilities.
This fixes the issue that a mount point would be treated as a
symlink, but readlink would subsequently return an NT namespaced
path that is unusable for many purposes.
This also pre-emptively fixes the problems that would arise when
an user has a reparse point whose tag is neither
IO_REPARSE_TAG_MOUNT_POINT nor IO_REPARSE_TAG_SYMLINK.
Finally uv_lstat() will now return the correct length in st_size.
Previously the length was computed incorrectly for relative
symlinks, and those that had non-ascii characters in their target.
Or rather, don't assume that dlopen() does *not* clobber dlerror().
Joe Ferner reports that loading libjava on OS X sets dlerror() even when
dlopen() succeeds, which makes uv_dlopen() raise an error when it shouldn't.
I haven't been able to reproduce it but it's possible that libjava clobbers
dlerror() by trying (and failing) to load other libraries.
At any rate, Joe confirmed that this patch addresses the issue.
Fixes#462.
Fixes a lifecycle issue where the req got created, added to the list of active
reqs but wasn't properly activated because uv__connect() returned early.
produces better error message from test-dgram-multicast-multi-process
when run w/o network.
before:
=== release test-dgram-multicast-multi-process ===
Path: simple/test-dgram-multicast-multi-process
dgram.js:287
throw new errnoException(errno, 'addMembership');
^
Error: addMembership Unknown system errno 19
at new errnoException (dgram.js:356:11)
at Socket.addMembership (dgram.js:287:11)
at Object.<anonymous> (/home/roman/wc/node/test/simple/test-dgram-multicast-multi-process.js:224:16)
at Module._compile (module.js:449:26)
at Object.Module._extensions..js (module.js:467:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)
at Module.runMain (module.js:487:10)
at process.startup.processNextTick.process._tickCallback (node.js:244:9)
[PARENT] Worker 9223 died. 1 dead of 3
dgram.js:287
throw new errnoException(errno, 'addMembership');
^
Error: addMembership Unknown system errno 19
at new errnoException (dgram.js:356:11)
at Socket.addMembership (dgram.js:287:11)
at Object.<anonymous> (/home/roman/wc/node/test/simple/test-dgram-multicast-multi-process.js:224:16)
at Module._compile (module.js:449:26)
at Object.Module._extensions..js (module.js:467:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)
at Module.runMain (module.js:487:10)
at process.startup.processNextTick.process._tickCallback (node.js:244:9)
[PARENT] sent 'First message to send' to 224.0.0.114:12346
dgram.js:287
[PARENT] sent 'Second message to send' to 224.0.0.114:12346
throw new errnoException(errno, 'addMembership');
[PARENT] sent 'Third message to send' to 224.0.0.114:12346
^
[PARENT] sendSocket closed
[PARENT] Worker 9224 died. 2 dead of 3
Error: addMembership Unknown system errno 19
at new errnoException (dgram.js:356:11)
at Socket.addMembership (dgram.js:287:11)
at Object.<anonymous> (/home/roman/wc/node/test/simple/test-dgram-multicast-multi-process.js:224:16)
at Module._compile (module.js:449:26)
at Object.Module._extensions..js (module.js:467:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)
at Module.runMain (module.js:487:10)
at process.startup.processNextTick.process._tickCallback (node.js:244:9)
[PARENT] Worker 9225 died. 3 dead of 3
[PARENT] All workers have died.
[PARENT] Fail
Command: out/Release/node /home/roman/wc/node/test/simple/test-dgram-multicast-multi-process.js
after:
=== release test-dgram-multicast-multi-process ===
Path: simple/test-dgram-multicast-multi-process
dgram.js:287
throw new errnoException(errno, 'addMembership');
^
Error: addMembership ENODEV
at new errnoException (dgram.js:356:11)
at Socket.addMembership (dgram.js:287:11)
at Object.<anonymous> (/home/roman/wc/node/test/simple/test-dgram-multicast-multi-process.js:224:16)
at Module._compile (module.js:449:26)
at Object.Module._extensions..js (module.js:467:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)
at Module.runMain (module.js:487:10)
at process.startup.processNextTick.process._tickCallback (node.js:244:9)
[PARENT] Worker 13141 died. 1 dead of 3
dgram.js:287
throw new errnoException(errno, 'addMembership');
^
[PARENT] sent 'First message to send' to 224.0.0.114:12346
[PARENT] sent 'Second message to send' to 224.0.0.114:12346
[PARENT] sent 'Third message to send' to 224.0.0.114:12346
[PARENT] sent 'Fourth message to send' to 224.0.0.114:12346
[PARENT] sendSocket closed
dgram.js:287
throw new errnoException(errno, 'addMembership');
^
Error: addMembership ENODEV
at new errnoException (dgram.js:356:11)
at Socket.addMembership (dgram.js:287:11)
at Object.<anonymous> (/home/roman/wc/node/test/simple/test-dgram-multicast-multi-process.js:224:16)
at Module._compile (module.js:449:26)
at Object.Module._extensions..js (module.js:467:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)
at Module.runMain (module.js:487:10)
at process.startup.processNextTick.process._tickCallback (node.js:244:9)
[PARENT] Worker 13142 died. 2 dead of 3
Error: addMembership ENODEV
at new errnoException (dgram.js:356:11)
at Socket.addMembership (dgram.js:287:11)
at Object.<anonymous> (/home/roman/wc/node/test/simple/test-dgram-multicast-multi-process.js:224:16)
at Module._compile (module.js:449:26)
at Object.Module._extensions..js (module.js:467:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)
at Module.runMain (module.js:487:10)
at process.startup.processNextTick.process._tickCallback (node.js:244:9)
[PARENT] Worker 13143 died. 3 dead of 3
[PARENT] All workers have died.
[PARENT] Fail
Command: out/Release/node /home/roman/wc/node/test/simple/test-dgram-multicast-multi-process.js
Newer versions of gyp do not support files with the same basenames (example:
core.c and linux/core.c).
The nominal reason is consistency across build systems. Apparently, msbuild
doesn't support it either.
Somewhere, someplace, baby Jesus cries sad little tears...
Fixes#464.
