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.
