2014.01.08, Version 0.10.22 (Stable)

Changes since version 0.10.21:

* windows: avoid assertion failure when pipe server is closed (Bert
Belder)

Now working on v0.11.18

2013.12.32, Version 0.11.17 (Unstable)

Changes since version 0.11.16:

* stream: allow multiple buffers for uv_try_write (Fedor Indutny)

* unix: fix a possible memory leak i

2013.12.32, Version 0.11.17 (Unstable)

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)

show more ...

unix: fix non-OSX builds

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 plat

unix: fix non-OSX builds

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.

show more ...

stream: fix uv__stream_osx_select

Relying on `readable`/`writable` when polling will lead to the select
thread spinning in the loop and calling `uv_async_send()`, because
stream may

stream: fix uv__stream_osx_select

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.

show more ...

doc: add libuv-dox to the documentation section

doc: add readme link to all projects that use libuv.

Revert "pipe: allow queueing pending handles"

The commit is quite broken and must be refactored before going into.

This reverts commit 08aeaf61935060e01f15cc1df2c9f09e892b0980.

pipe: allow queueing pending handles

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`
mu

pipe: allow queueing pending handles

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

show more ...

osx: Fix a possible segfault in uv__io_poll

In our build infrastructure, I've seen a lot of segfaults recently that
were all only happening on OSX. Upon inspecting the coredumps, it

osx: Fix a possible segfault in uv__io_poll

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.

show more ...

osx: Fix a possible segfault in uv__io_poll

In our build infrastructure, I've seen a lot of segfaults recently that
were all only happening on OSX. Upon inspecting the coredumps, it

osx: Fix a possible segfault in uv__io_poll

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.

show more ...

Merge branch 'v0.10'

Conflicts:
build.mk
Makefile.am
test/test-ipc.c

test: make test-pipe-server-close pass on linux

When a server and a client are both part of the same event loop, and
the client connects to the server, the order in which the connect

test: make test-pipe-server-close pass on linux

When a server and a client are both part of the same event loop, and
the client connects to the server, the order in which the connect
callback and the connection callback are called is unspecified.
Apparently on linux the connection callback sometimes happens first,
which is not a bug, and should not make this test fail.

show more ...

test: add pipe-server-close test

Add a regression test for the pipe server close issue on Windows, which
was reported in joyent/node#6749 and fixed in 7b16a3f.

code style: strip trailing whitespace

Merge branch 'v0.10'

Conflicts:
AUTHORS
ChangeLog
src/version.c

windows: avoid assertion failure when pipe server is closed

When a pipe server is closed, all pending accept requests and their
associated HANDLEs are closed to force windows to cancel t

windows: avoid assertion failure when pipe server is closed

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.

show more ...

unix, windows: add uv_loop_alive() function

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 mig

unix, windows: add uv_loop_alive() function

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

show more ...

Now working on v0.10.22

2013.12.19, Version 0.10.21 (Stable)

Changes since version 0.10.20:

* unix: fix a possible memory leak in uv_fs_readdir (Alex Crichton)

build: ignore generated makefiles on android

gyp currently doesn't support the --generator-output option for android,
this is the best way to ignore generated files for projects using li

build: ignore generated makefiles on android

gyp currently doesn't support the --generator-output option for android,
this is the best way to ignore generated files for projects using libuv
as a dependency.

show more ...

test: allow UV_EACCES in spawn_fails

Allow UV_EACCES as a successful return value when uv_spawn fails.

When the PATH environment variable contains a directory which the
user can

test: allow UV_EACCES in spawn_fails

Allow UV_EACCES as a successful return value when uv_spawn fails.

When the PATH environment variable contains a directory which the
user cannot access, execvp may return EACCES instead of ENOENT.

fix #1045.

show more ...

unix: fix a possible memory leak in uv_fs_readdir

Some scandir implementations allocate the dirent struct even if the
directory is empty, so if `scandir` returns 0 there may still be mem

unix: fix a possible memory leak in uv_fs_readdir

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.

show more ...

build: add support for VS2013

stream: allow multiple buffers for uv_try_write