589c224d | 31-Dec-2013 |
Timothy J Fontaine |
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 ...
|
17648be2 | 28-Dec-2013 |
River Tarnell |
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 ...
|
08cafd09 | 20-Dec-2013 |
Fedor Indutny |
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 ...
|
7d23c1d7 | 27-Dec-2013 |
Saúl Ibarra Corretgé |
doc: add libuv-dox to the documentation section |
20253414 | 24-Dec-2013 |
Andrius Bentkus |
doc: add readme link to all projects that use libuv. |
8b6c19e2 | 23-Dec-2013 |
Fedor Indutny |
Revert "pipe: allow queueing pending handles" The commit is quite broken and must be refactored before going into. This reverts commit 08aeaf61935060e01f15cc1df2c9f09e892b0980. |
08aeaf61 | 22-Dec-2013 |
Fedor Indutny |
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 ...
|
f166d6d7 | 22-Dec-2013 |
Alex Crichton |
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 ...
|
f6422af8 | 22-Dec-2013 |
Alex Crichton |
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 ...
|
140c863f | 21-Dec-2013 |
Bert Belder |
Merge branch 'v0.10' Conflicts: build.mk Makefile.am test/test-ipc.c
|
16c4b21e | 21-Dec-2013 |
Bert Belder |
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 ...
|
c66340d5 | 21-Dec-2013 |
Bert Belder |
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. |
562d7a49 | 21-Dec-2013 |
Bert Belder |
code style: strip trailing whitespace |
46a06021 | 21-Dec-2013 |
Bert Belder |
Merge branch 'v0.10' Conflicts: AUTHORS ChangeLog src/version.c
|
7b16a3f5 | 21-Dec-2013 |
Bert Belder |
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 ...
|
ed36b85d | 17-May-2013 |
Sam Roberts |
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 ...
|
9d60214b | 18-Dec-2013 |
Timothy J Fontaine |
Now working on v0.10.22 |
375ebce0 | 18-Dec-2013 |
Timothy J Fontaine |
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) |
4a7a72fb | 03-Dec-2013 |
Steven Kabbes |
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 ...
|
b44edf31 | 16-Dec-2013 |
Joshua Neuheisel |
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 ...
|
7c6bddbe | 17-Dec-2013 |
Alex Crichton |
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 ...
|
a762934a | 13-Dec-2013 |
Sean Farrell |
build: add support for VS2013 |
17d60e3f | 13-Dec-2013 |
Fedor Indutny |
stream: allow multiple buffers for uv_try_write |
7f65a74f | 13-Dec-2013 |
Fedor Indutny |
test: remove C++ style comment |
333a5b73 | 13-Dec-2013 |
Timothy J Fontaine |
Now working on v0.11.17 |