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.
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.
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.
