libuv/libuv

Cross-platform asynchronous I/O

Overview

libuv is a multi-platform support library with a focus on asynchronous I/O. It was primarily developed for use by Node.js, but it's also used by Luvit, Julia, uvloop, and others.

Feature highlights

• Full-featured event loop backed by epoll, kqueue, IOCP, event ports.

• Asynchronous TCP and UDP sockets

• Asynchronous DNS resolution

• Asynchronous file and file system operations

• File system events

• ANSI escape code controlled TTY

• IPC with socket sharing, using Unix domain sockets or named pipes (Windows)

• Child processes

• Thread pool

• Signal handling

• High resolution clock

• Threading and synchronization primitives

Versioning

Starting with version 1.0.0 libuv follows the semantic versioning scheme. The API change and backwards compatibility rules are those indicated by SemVer. libuv will keep a stable ABI across major releases.

The ABI/API changes can be tracked here.

Licensing

libuv is licensed under the MIT license. Check the LICENSE and LICENSE-extra files.

The documentation is licensed under the CC BY 4.0 license. Check the LICENSE-docs file.

Community

• Support
• Mailing list

Documentation

Official documentation

Located in the docs/ subdirectory. It uses the Sphinx framework, which makes it possible to build the documentation in multiple formats.

Show different supported building options:

$ make help

Build documentation as HTML:

$ make html

Build documentation as HTML and live reload it when it changes (this requires sphinx-autobuild to be installed and is only supported on Unix):

$ make livehtml

Build documentation as man pages:

$ make man

Build documentation as ePub:

$ make epub

NOTE: Windows users need to use make.bat instead of plain 'make'.

Documentation can be browsed online here.

The tests and benchmarks also serve as API specification and usage examples.

Other resources

• LXJS 2012 talk — High-level introductory talk about libuv.
• libuv-dox — Documenting types and methods of libuv, mostly by reading uv.h.
• learnuv — Learn uv for fun and profit, a self guided workshop to libuv.

These resources are not handled by libuv maintainers and might be out of date. Please verify it before opening new issues.

Downloading

libuv can be downloaded either from the GitHub repository or from the downloads site.

Before verifying the git tags or signature files, importing the relevant keys is necessary. Key IDs are listed in the MAINTAINERS file, but are also available as git blob objects for easier use.

Importing a key the usual way:

$ gpg --keyserver pool.sks-keyservers.net --recv-keys AE9BC059

Importing a key from a git blob object:

$ git show pubkey-saghul | gpg --import

Verifying releases

Git tags are signed with the developer's key, they can be verified as follows:

$ git verify-tag v1.6.1

Starting with libuv 1.7.0, the tarballs stored in the downloads site are signed and an accompanying signature file sit alongside each. Once both the release tarball and the signature file are downloaded, the file can be verified as follows:

$ gpg --verify libuv-1.7.0.tar.gz.sign

Build Instructions

For UNIX-like platforms, including macOS, there are two build methods: autotools or CMake.

For Windows, CMake is the only supported build method and has the following prerequisites:

• One of:
  • Visual C++ Build Tools
  • Visual Studio 2015 Update 3, all editions including the Community edition (remember to select "Common Tools for Visual C++ 2015" feature during installation).
  • Visual Studio 2017, any edition (including the Build Tools SKU). Required Components: "MSbuild", "VC++ 2017 v141 toolset" and one of the Windows SDKs (10 or 8.1).
• Basic Unix tools required for some tests, Git for Windows includes Git Bash and tools which can be included in the global PATH.

To build with autotools:

$ sh autogen.sh
$ ./configure
$ make
$ make check
$ make install

To build with CMake:

$ mkdir -p build

$ (cd build && cmake .. -DBUILD_TESTING=ON) # generate project with tests
$ cmake --build build                       # add `-j <n>` with cmake >= 3.12

# Run tests:
$ (cd build && ctest -C Debug --output-on-failure)

# Or manually run tests:
$ build/uv_run_tests                        # shared library build
$ build/uv_run_tests_a                      # static library build

To cross-compile with CMake (unsupported but generally works):

$ cmake ../..                 \
  -DCMAKE_SYSTEM_NAME=Windows \
  -DCMAKE_SYSTEM_VERSION=6.1  \
  -DCMAKE_C_COMPILER=i686-w64-mingw32-gcc

Install with Homebrew

$ brew install --HEAD libuv

Note to OS X users:

Make sure that you specify the architecture you wish to build for in the "ARCHS" flag. You can specify more than one by delimiting with a space (e.g. "x86_64 i386").

Install with vcpkg

$ git clone https://github.com/microsoft/vcpkg.git
$ ./bootstrap-vcpkg.bat # for powershell
$ ./bootstrap-vcpkg.sh # for bash
$ ./vcpkg install libuv

Running tests

Some tests are timing sensitive. Relaxing test timeouts may be necessary on slow or overloaded machines:

$ env UV_TEST_TIMEOUT_MULTIPLIER=2 build/uv_run_tests # 10s instead of 5s

Run one test

The list of all tests is in test/test-list.h.

This invocation will cause the test driver to fork and execute TEST_NAME in a child process:

$ build/uv_run_tests_a TEST_NAME

This invocation will cause the test driver to execute the test in the same process:

$ build/uv_run_tests_a TEST_NAME TEST_NAME

Debugging tools

When running the test from within the test driver process (build/uv_run_tests_a TEST_NAME TEST_NAME), tools like gdb and valgrind work normally.

When running the test from a child of the test driver process (build/uv_run_tests_a TEST_NAME), use these tools in a fork-aware manner.

Fork-aware gdb

Use the follow-fork-mode setting:

$ gdb --args build/uv_run_tests_a TEST_NAME

(gdb) set follow-fork-mode child
...

Fork-aware valgrind

Use the --trace-children=yes parameter:

$ valgrind --trace-children=yes -v --tool=memcheck --leak-check=full --track-origins=yes --leak-resolution=high --show-reachable=yes --log-file=memcheck-%p.log build/uv_run_tests_a TEST_NAME

Running benchmarks

See the section on running tests. The benchmark driver is ./uv_run_benchmarks_a and the benchmarks are listed in test/benchmark-list.h.

Supported Platforms

Check the SUPPORTED_PLATFORMS file.

-fno-strict-aliasing

It is recommended to turn on the -fno-strict-aliasing compiler flag in projects that use libuv. The use of ad hoc "inheritance" in the libuv API may not be safe in the presence of compiler optimizations that depend on strict aliasing.

MSVC does not have an equivalent flag but it also does not appear to need it at the time of writing (December 2019.)

AIX Notes

AIX compilation using IBM XL C/C++ requires version 12.1 or greater.

AIX support for filesystem events requires the non-default IBM bos.ahafs package to be installed. This package provides the AIX Event Infrastructure that is detected by autoconf. IBM documentation describes the package in more detail.

z/OS Notes

z/OS compilation requires ZOSLIB to be installed. When building with CMake, use the flag -DZOSLIB_DIR to specify the path to ZOSLIB:

$ (cd build && cmake .. -DBUILD_TESTING=ON -DZOSLIB_DIR=/path/to/zoslib)
$ cmake --build build

z/OS creates System V semaphores and message queues. These persist on the system after the process terminates unless the event loop is closed.

Use the ipcrm command to manually clear up System V resources.

Patches

See the guidelines for contributing.

libuv's Issues

libuv.org is empty

The current website is almost empty with a simple folder called dist in it.

Hit assert() in uv__async_io()

124 
125 static void uv__async_io(uv_loop_t* loop, uv__io_t* w, unsigned int events) {
126   struct uv__async* wa;
127   char buf[1024];
128   unsigned n;
129   ssize_t r;
130 
131   n = 0;
132   for (;;) {
133     r = read(w->fd, buf, sizeof(buf));
134 
135     if (r > 0)
136       n += r;
137 
138     if (r == sizeof(buf))
139       continue;
140 
141     if (r != -1)
142       break;
143 
144     if (errno == EAGAIN || errno == EWOULDBLOCK)
145       break;
146 
147     if (errno == EINTR)
148       continue;
149 
150     abort();
151   }
152 
153   wa = container_of(w, struct uv__async, io_watcher);
154 
155 #if defined(__linux__)
156   if (wa->wfd == -1) {
157     uint64_t val;
158     assert(n == sizeof(val));
159     memcpy(&val, buf, sizeof(val));  /* Avoid alignment issues. */
160     wa->cb(loop, wa, val);
161     return;
162   }
163 #endif
164 
165   wa->cb(loop, wa, n);
166 }
167 

Our project often hit assert() in line 158 because read() in line 133 sometimes returns -1.
I think this piece of code makes a mistake when dealing with EAGAIN or EWOULDBLOCK.

Help me.

[2.0 RFC] Request all the things

EDIT: the proposal is now here: libuv/leps#2

Please read the README for information on the LEP process: https://github.com/libuv/leps/blob/master/README.md

uv_udp_set_multicast_loop doesn't do anything on IPv6

While I was experimenting with multicast I found that the uv_udp_set_multicast_loop function wasn't failing but wasn't working either. After looking through the UDP source code, I found that uv_udp_set_multicast_loop, uv_udp_set_multicast_ttl, and uv_udp_set_ttl all set their respective IPv4 socket options, but have no logic to set their respective IPv6 socket options.

I believe the reason why this hasn't caused an error is that dual-stack is enabled by default and it's setting the options for the IPv4 packets but not for IPv6 packets.

The simpliest solution would be to make these three functions IP specific but then that would retract from the unification of IPv4 and IPv6.

Another solution be to drop uv_udp_set_multicast_loop and provide the option as a flag on bind, but then there is still the issue with the two ttl functions.

Overall I believe this problem should be handled with caution.

Edit:
I tried setting UV_UDP_IPV6ONLY and found that setsockopt still doesn't fail when setting IPv4 socket options on an IPv6 socket.

Cross platform passwd functions

Moved from joyent/libuv#468

@isaacs said:

Regarding: nodejs/node-v0.x-archive#2857

It'd be lovely if there was a way to call a uv_* version of the pwnam family of functions. See man 3 pwnam.

This is needed to reliably and quickly get the home directory path. The home directory path is needed by a lot of node modules, but in some environments the $HOME environment variable is not defined. This can make all kinds of things fail as most code depend on it being defined. The same applies for getting the username of the current user, which is also currently slow and convoluted.

how to build libuv with gcc 4.3.X

the function __sync_val_compare_and_swap is in gcc 4.4,so i can't build it with arm gcc 4.3.2.
MUTEX LOCK *PTR==oldval?newval RETURN *PTR==oldval UNLOCK????,it is better to do?

win: dlerror test fails

Any idea why this fails on my machine? I added already some debug output:

`dlerror` failed: exit code 3
Output from process `dlerror`:
msg = 'no error'
dlerror_desc = '%1 is not a valid Win32 application'
Assertion failed in .\test\test-dlerror.c on line 50: strstr(msg, dlerror_desc) != NULL

libuv loop is thread safe?

thread1{
loop()
}
thread2{
loop()
}
is it thread safe?
thread1{
epoll()
}
thread2{
epoll()
}
this is threadsafe.how about libuv loop?

barrier_* test fail on FreeBSD 11

Haven't tested on 10 (not available at the moment), but the barrier tests fail with return code 134 (no output) on a FreeBSD-current amd64 setup.

#0  0x000000080116590a in thr_kill () from /lib/libc.so.7
No symbol table info available.
#1  0x00000008012289b9 in abort () from /lib/libc.so.7
No symbol table info available.
#2  0x00000008008b4bd5 in uv_barrier_destroy (barrier=0x7fffffffe8a0) at thread.c:487
No locals.
#3  0x000000000040bc2c in run_test_barrier_1 () at test/test-barrier.c:60
    thread = 0x801c06800
    wc = {barrier = 0x801c17060, delay = 0, posted = 0, main_barrier_wait_rval = 1, worker_barrier_wait_rval = 0}
#4  0x000000000040a3be in run_test_part (test=0x7fffffffec69 "barrier_1", part=0x7fffffffec73 "barrier_1") at test/runner.c:395
    task = (task_entry_t *) 0x679cd0
    r = 8
#5  0x00000000004088da in main (argc=3, argv=0x7fffffffe9a8) at test/run-tests.c:56
No locals.

I'm rebuilding my kernel with debug info tomorrow, will paste a better traceback then.

Is there an API similiar to `fork()`? Or why there isn't a function like `uv_fork()`?

And what is the best solution, when I need to fork a sub process because the sub-process may crash, so I can't use thread to do that?

use uv_tcp_keepalive on windows xp will cause uv_tcp_connect fail

If I use uv_tcp_keepalive with argument on windows xp before uv_tcp_connect,
will cause uv_tcp_connect return -1, uv_last_error shows -1 unknow error.
This problem only on windows xp, not on windows 7 or later.

core: release 1.1.0

I kind of fucked up the 1.0.2 release. It contained a new API (9da5fd4) so it should have been 1.1.0. Sorry! :-S

Any objections to releasing 1.1.0? @bnoordhuis @piscisaureus

To prevent this from happening again, we might want to bump the minor and reset the is_release thing if a new API is added, thus indicating which version needs to be the next one.

Test fails on Ubuntu 12.04.3 LTS

This test fails on Ubuntu 12.04.3 LTS. libuv is built from repo and the same error is thrown on version tagged 'v1.0.1' as well as on latest from master (96d9028...):

=============================================================
[%  58|+ 142|-   0|T   0|S   0]: get_currentexe
`get_currentexe` failed: exit code 134
Output from process `get_currentexe`:
Assertion failed in test/test-get-currentexe.c on line 53: match && !strcmp(match, path)
=============================================================

Write after ECONNRESET crash.

I write Lua binding to libuv.
Server just accept socket and close it. For this I use basic socket library(not libuv)

while true do
  local control = server:accept()
  control:close()
end

Client just connect to server and call uv_write until it get error result or callback status.

local uv = require "lluv"

local host = host or "127.0.0.1"
local port = port or "8383"

local function write(s, data, cb)
  local ok, err = s:write(data, cb)
  if not ok then cb(s, err) end
  return true
end

local i = 1
local function on_write(cli, err)
  if err then
    print(">>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>")
    print(cli, err)
    print(">>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>")
    return
  end
  print("Write #" .. i .. " done.")
  i = i + 1
  write(cli, "hello", on_write)
end

uv.tcp():connect(host, port, function(cli, err)
  if err then
    cli:close()
    assert(false, tostring(err))
  end
  write(cli, "hello", on_write)
end)

uv.run()

This test case works on Windows but on Linux Mint 15 or on Travis it could just crash with error code 141. But some times it pass.
Also it crash every time if I try write after uv_write return ECONNRESET(on Linux not on Windows)
On windows I just get same error each time.

document more precise semantics for uv_async_send

The documentation for uv_async_send states:

calling this function may not wakeup the event loop if it was already called previously within a short period of time

"within a short period of time" does not meaningfully strengthen the contract of uv_async_send; based on this documentation, one must assume that the following is a possible sequence of execution:

Event loop thread	Second thread
	uv_async_send
callback execution begins
callback execution completes
	uv_async_send
(callback never executed a second time)

Is that indeed a possible sequence of execution? If so, I suggest replacing the text "within a short period of time" with "for the given async handle", making it clearer that the strongest guarantee made is that the callback will be executed once, ever.

If uv_async_send actually makes stronger guarantees, then please document them precisely. For example, a useful stronger guarantee would be that the callback is executed consistent with a model where uv_async_send atomically sets a "needs execution" flag, and the event loop atomically resets this flag before running the callback. That would rule out the sequence of execution above.

Delete old branches if they can be

• https://github.com/libuv/libuv/tree/cpp-ify (created by @bnoordhuis)
• https://github.com/libuv/libuv/tree/ipc_threads (created by @igorzi; I'll take responsibility for that)
• https://github.com/libuv/libuv/tree/no-linger (created by @bnoordhuis)
• https://github.com/libuv/libuv/tree/prefork (created by @piscisaureus)
• https://github.com/libuv/libuv/tree/threadpool-rework (@bnoordhuis again)

The windows branches can go; both ipc_threads and prefork are good ideas (both related to making single-process "cluster" easier/faster). I expect the ideas to re-emerge in future libuv, but the patches are stale and we can drop them.

linux: fs_fstat test fails with gyp build

v1.x dfdcfc0:

$ ./gyp_uv
['/home/bnoordhuis/src/libuv/uv.gyp', '-I', '/home/bnoordhuis/src/libuv/common.gypi', '--depth=.', '-f', 'make', '-Goutput_dir=/home/bnoordhuis/src/libuv/out', '--generator-output', '/home/bnoordhuis/src/libuv/out', '-Dgcc_version=49', '-Dclang=0', '-Dhost_arch=x64', '-Dtarget_arch=x64', '-Duv_library=static_library', '-Dcomponent=static_library']

$ make -C out BUILDTYPE=Debug
# elided

$ out/Debug/run-tests fs_fstat fs_fstat
Assertion failed in ../test/test-fs.c on line 1081: s->st_atim.tv_nsec == t.st_atim.tv_nsec
Aborted (core dumped)

$ file out/Debug/run-tests 
out/Debug/run-tests: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=f55d2937f14fa096a1e2bce1d6986f1671ecd261, not stripped

$ uname -a
Linux localhost.localdomain 3.17.3-300.fc21.x86_64 #1 SMP Fri Nov 14 23:36:19 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

The autotools build works, the test only fails when building with gyp. A quick investigation suggests that neither _BSD_SOURCE, _SVID_SOURCE or _XOPEN_SOURCE are defined, making src/unix/fs.c skip the tv_nsec fields.

Feature request: SSL

Lots people seem to want it, but libuv lacks SSL support. Support for SSL in libuv (or as an add-on to libuv) would make adopting libuv easier. OpenSSL is hard to get right, and thus a lot of effort for the application.

Bonus points for Apple's Security framework, where available.

DragonFly regression (joyent/libuv issue 1576)

The following patch "fixes" the DragonFly regression outlined in the issue 1576.

--- Makefile.am.orig    2014-12-16 02:24:38 UTC
+++ Makefile.am
@@ -274,7 +274,6 @@ endif

 if DRAGONFLY
 include_HEADERS += include/uv-bsd.h
-libuv_la_SOURCES += src/unix/kqueue.c src/unix/freebsd.c
 endif

 if FREEBSD

I don't know why FreeBSD doesn't have the same problem though. I'd have thought it would.

Expose uv_translate_sys_error?

It would be nice if it were possible for user code which runs posix syscalls to return uv_err_t. However, that's not the case, because uv_translate_sys_error, despite its singly-underscored name, is not exposed publicly. (This also makes it difficult to translate the error into a string like 'ENOENT'; you can use strerror but that just provides the long English string.)

I realize that the function is Unix-specific and would require some sort of Windows stub (or for users to #ifdef _WIN32, but it still seems useful.

2 tests in test-spawn fail

Gentoo Linux, libuv-1.0.1
model: Intel(R) Core(TM) i3-2350M CPU @ 2.30GHz

spawn_reads_child_path failed: exit code 6
Output from process spawn_reads_child_path:
exit_cb
Assertion failed in /var/tmp/portage/dev-libs/libuv-1.0.1/work/libuv-1.0.1/test/test-spawn.c on line 66: exit_status == 1

spawn_setuid_setgid failed: exit code 6
Output from process spawn_setuid_setgid:
Assertion failed in /var/tmp/portage/dev-libs/libuv-1.0.1/work/libuv-1.0.1/test/test-spawn.c on line 1054: r == 0

nodejs shows SIGABRT (Aborted) @ 0 (0) on x64 CentOS

As a followup to this issue in nodejs mailing list (https://groups.google.com/forum/#!topic/nodejs/3AUlFk_oLi8).

The original issue was,
While running nodejs installed via Python 2.75 in a 64 bit Centos (5.11) version showed "Aborted" Error.

The issue was submitted in nodejs mailing. As per, Ben Noordhuis, this deals with an error code (-293) which is not possible as the limit that is set for error code is (-133) to (-1).

As requested, the details of the Unix box as follows.

1. uname -a : Linux clms-uat-app1.unicon.net 2.6.18-xenU-ec2-v1.4 #1 SMP Wed Dec 2 05:20:19 UTC 2009 x86_64 x86_64 x86_64 GNU/Linux
2. cat /etc/*elease : CentOS release 5.11 (Final)

Talked with quite a few devs in IRC, and they suggested me to use the x86 binary. So I downloaded both x64 & x86 and tried to strace both node executable in bin directory. The diff is as: https://gist.github.com/aneek/10abdb5d1e91a21cfcd6

64 bit again showed the Abort while 32 bit started to work as expected.

cwd_and_chdir test failure

This is caused by uv_cwd's signature and how the test works.

int uv_cwd(char* buf, size_t* size).
The size argument is used to specify a pointer to a variable holding the size of the buffer. It must include room for a terminating null. It is also used to return the length of the current working directory, however the terminating null is not counted.

The test does this:

r = uv_cwd(buf, &size);
ASSERT(r == 0);
...
r = uv_cwd(buf, &size);
ASSERT(r == 0);

That means that the second time uv_cwd will fail because, because size is now the length of the current directory excluding the terminating null, so in the second round uv_cwd() figures that the buffer is too small to hold the current working directory path including terminating null.

My suggestion would be to change the uv_cwd() signature so it includes the terminating null.

But before going there, I first need to understand why this test doesn't fail on linux. According to the man page:

If the length of the absolute pathname of the current working directory, including the terminating null byte, exceeds size bytes, NULL is returned, and errno is set to ERANGE

So I would expect this test to fail on linux too. @bnoordhuis can you maybe shed some light on this, because I have no idea.

1.0.0: ipv6 tests fail when they should skip/avoid

I still get a lot of fails when disabling ipv6 in my linux kernel (3.17.2). Shouldn't these really be skips?

[%  13|+  34|-   0|T   0|S   0]: tcp_ping_pong_v6
`tcp_ping_pong_v6` failed: exit code 6
Output from process `tcp_ping_pong_v6`:
IPv6 not supported
Output from process `tcp_ping_pong_v6`:
Assertion failed in /tmp/libuv-1.0.0/test/test-ping-pong.c on line 176: !r
=============================================================
[%  25|+  61|-   1|T   0|S   0]: tcp_bind6_error_addrinuse
`tcp_bind6_error_addrinuse` failed: exit code 6
Output from process `tcp_bind6_error_addrinuse`:
Assertion failed in /tmp/libuv-1.0.0/test/test-tcp-bind6-error.c on line 47: r == 0
=============================================================
[%  25|+  61|-   2|T   0|S   0]: tcp_bind6_error_addrnotavail
`tcp_bind6_error_addrnotavail` failed: exit code 6
Output from process `tcp_bind6_error_addrnotavail`:
Assertion failed in /tmp/libuv-1.0.0/test/test-tcp-bind6-error.c on line 81: r == UV_EADDRNOTAVAIL
=============================================================
[%  26|+  62|-   3|T   0|S   0]: tcp_bind6_error_inval
`tcp_bind6_error_inval` failed: exit code 6
Output from process `tcp_bind6_error_inval`:
Assertion failed in /tmp/libuv-1.0.0/test/test-tcp-bind6-error.c on line 132: r == 0
=============================================================
[%  27|+  62|-   4|T   0|S   0]: tcp_bind6_localhost_ok
`tcp_bind6_localhost_ok` failed: exit code 6
Output from process `tcp_bind6_localhost_ok`:
Assertion failed in /tmp/libuv-1.0.0/test/test-tcp-bind6-error.c on line 157: r == 0
=============================================================
[%  30|+  68|-   5|T   0|S   0]: udp_dual_stack
`udp_dual_stack` failed: exit code 6
Output from process `udp_dual_stack`:
Assertion failed in /tmp/libuv-1.0.0/test/test-udp-ipv6.c on line 112: r == 0
=============================================================
[%  30|+  68|-   6|T   0|S   0]: udp_ipv6_only
`udp_ipv6_only` failed: exit code 6
Output from process `udp_ipv6_only`:
Assertion failed in /tmp/libuv-1.0.0/test/test-udp-ipv6.c on line 112: r == 0
=============================================================
[%  32|+  71|-   7|T   0|S   0]: udp_multicast_interface6
`udp_multicast_interface6` failed: exit code 6
Output from process `udp_multicast_interface6`:
Assertion failed in /tmp/libuv-1.0.0/test/test-udp-multicast-interface6.c on line 70: r == 0
=============================================================
[%  32|+  72|-   8|T   0|S   0]: udp_multicast_join6
`udp_multicast_join6` failed: exit code 6
Output from process `udp_multicast_join6`:
Assertion failed in /tmp/libuv-1.0.0/test/test-udp-multicast-join6.c on line 116: r == 0
=============================================================

Either skip compile/running them or perhaps introduce a convenience method that checks for ipv6 support before calling the functions through tests.

mac: osx_select_many_fds broken with low ulimit

v1.x dfdcfc0:

$ ulimit -n
256

$ out/Debug/run-tests osx_select_many_fds osx_select_many_fds
Assertion failed in ../test/test-osx-select.c on line 100: r == 0
Abort trap: 6

$ ulimit -n 8192

$ out/Debug/run-tests osx_select_many_fds osx_select_many_fds
got some input
with a couple of lines
feel pretty happy
got data 1
got data 2
got data 3

Empty dist directory

http://libuv.org/dist/v1.0.2/ is empty!

uv_send_buffer_size does not allow you to set SO_SNDBUF to 0

Using 0 to wrap getsockopt within uv__socket_sockopt prevents us from using uv_send_buffer_size to set SO_SNDBUF socket option to 0 (zero) which on Windows would allow the stack to send from your application buffer directly.

RFC: single "base class" for uv_handle_t and uv_req_t

I would like to have a single base type for handles and requests, and the uv_handle_type and uv_req_type types should share a name space.

The reason for this move is that it'll allow me to put requests and handles in the same queue, so I can get rid of a separate "endgame queue". That will quite easily let unix and windows share the same event loop core.

typedef struct {
  uv_object_type_t type;
  void* queue[2];
   void* data;
} uv_object_t;

Test issues in Linux

• Linux Debian Wheezy 64 bits
• libuv v1.x

=============================================================
[%  59|+ 144|-   0|T   0|S   0]: cwd_and_chdir
`cwd_and_chdir` failed: exit code 6
Output from process `cwd_and_chdir`:
Assertion failed in test/test-cwd-and-chdir.c on line 63: size1 == size2
=============================================================
[%  75|+ 183|-   1|T   0|S   0]: spawn_setuid_setgid
`spawn_setuid_setgid` failed: exit code 6
Output from process `spawn_setuid_setgid`:
Assertion failed in test/test-spawn.c on line 1054: r == 0
=============================================================

First issue is already fixed in #63.

windows: make check fails to compile due undefined reference run_test_poll_close_doesnt_corrupt_stack

• Windows 7 Ultimate x64
• GCC: 4.7.2 (rubenvb-4.7.2-release)
• Using
• configure options: --enable-shared --enable-static --prefix=V:/libuv/1.02

Seems the issue is caused by missing test/test-poll-close-doesnt-corrupt-stack.c for test_run_tests_SOURCES (in Makefile.am)

But I wasn't sure to send a pull request considering the test file is only for _WIN32.

Perhaps needs to be added around WINNT check? (like the runner)

Please let me know and I'll send a pull request.

Thank you!

Build test failed on beaglebone ubuntu

I'm trying to install libuv on beaglebone ubuntu and failed on make check.

make  check-TESTS
make[1]: Entering directory `/root/libuv-1.x'
[%   0|+   0|-   0|T   0|S   0]: platform_output
Output from process `platform_output`:
uv_get_process_title: /root/libuv-1.x/test/.libs/lt-run-tests
uv_resident_set_memory: 643072
uv_uptime: 1707.000000
uv_getrusage:
  user: 0 sec 1953 microsec
  system: 0 sec 5859 microsec
uv_cpu_info:
  model: ARMv7 Processor rev 2 (v7l)
  speed: 600
  times.sys: 1137900
  times.user: 3947300
  times.idle: 11561800
  times.irq: 0
  times.nice: 0
uv_interface_addresses:
  name: lo
  internal: 1
  physical address: 00:00:00:00:00:00
  address: 127.0.0.1
  netmask: 255.0.0.0
  name: wlan4
  internal: 0
  physical address: 80:3f:5d:20:7f:6d
  address: 10.0.10.189
  netmask: 255.255.255.0
  name: lo
  internal: 1
  physical address: 00:00:00:00:00:00
  address: ::1
  netmask: ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff
  name: wlan4
  internal: 0
  physical address: 80:3f:5d:20:7f:6d
  address: fe80::823f:5dff:fe20:7f6d
  netmask: ffff:ffff:ffff:ffff::
=============================================================
[%  16|+  39|-   0|T   0|S   0]: tcp_writealot
`tcp_writealot` failed: timeout
Output from process `tcp_writealot`: (no output)
Output from process `tcp_writealot`: (no output)
=============================================================
[%  59|+ 143|-   1|T   0|S   0]: cwd_and_chdir
`cwd_and_chdir` failed: exit code 6
Output from process `cwd_and_chdir`:
Assertion failed in test/test-cwd-and-chdir.c on line 63: size1 == size2
=============================================================
[%  75|+ 182|-   2|T   0|S   0]: spawn_setuid_setgid
`spawn_setuid_setgid` failed: exit code 6
Output from process `spawn_setuid_setgid`:
Assertion failed in test/test-spawn.c on line 1054: r == 0
=============================================================
[% 100|+ 240|-   3|T   0|S   0]: Done.
FAIL: test/run-tests
======================================================
1 of 1 tests failed
Please report to https://github.com/libuv/libuv/issues
======================================================
make[1]: *** [check-TESTS] Error 1
make[1]: Leaving directory `/root/libuv-1.x'
make: *** [check-am] Error 2

UV_RUN_ONCE blocks even after executing a callback

Cheers,

I'm trying to debug an issue when using libuv in windows with Neovim (neovim/neovim#810), Neovim repeatedly calls uv_run(UV_RUN_ONCE) to process events, but in windows the call sometimes blocks even if one of the read callbacks was invoked.

The program listens on a TCP socket, and waits for a read callback, my assumption was that if a single callback was invoked (in a call to uv_run(UV_RUN_ONCE)) then uv_run would return - at least that seems to be the case in Linux. Instead I'm seeing the following when a client sends some TCP data

1. We call uv_run(UV_RUN_ONCE)
2. uv_run() calls uv_process_reqs() that in turn invokes our read callback, that reads the data from the socket
3. uv_run blocks calling poll() and does not return

the program is now blocked in uv_run, sending more data via the same socket will cause it to return, but it also causes it to behave differently

1. (we are still blocked in uv_run() -> poll())
2. The call to uv_run exits we do some work, and write a response to the socket
3. Again we call uv_run(UV_RUN_ONCE)
4. Our read callback gets invoked with the new data
5. uv_run exits (as I would expect)

The pattern repeats itself for every time we send data through the socket i.e. odd requets block uv_run, even ones do not.

Maybe my assumptions about UV_RUN_ONCE are wrong?. Looking at src/win/core.c:uv_run() seems to poll regardless of what uv_process_reqs does, but then uv.h says

 *  - UV_RUN_ONCE: Poll for new events once. Note that this function blocks if
 *    there are no pending events. Returns zero when done (no active handles
 *    or requests left), or non-zero if more events are expected (meaning you
 *    should run the event loop again sometime in the future).

or am I supposed to do something else to ensure poll returns at that point.

Creation of full duplex pipe via spawn causes deadlock on Windows

Recently tried to use the UV_CREATE_PIPE support in spawn to create a full duplex pipe. The methodology used is as follows:

Parent Process:

1. Create a full duplex pipe on stderr shortly before calling spawn:

    uv_pipe_init(loop, &pipe_, 0);
    const int kFlags = UV_CREATE_PIPE  | UV_READABLE_PIPE | UV_WRITABLE_PIPE;
    slots[2].flags = static_cast<uv_stdio_flags>(kFlags);
    slots[2].data.stream = reinterpret_cast<uv_stream_t*>(&pipe_);

2. Start read on the newly created pipe:

    uv_read_start(reinterpret_cast<uv_stream_t*>(&pipe_), onAlloc, onRead);

Child Process:

1. Create a pipe object using uv_pipe_open:

    uv_loop_t* loop = uv_default_loop();
    uv_pipe_init(loop, &pipe_, 0);
    int rval = uv_pipe_open(&pipe_, 2);

2. Start read on newly created pipe:

    uv_read_start(reinterpret_cast<uv_stream_t*>(&pipe_), onAlloc, onRead);

3. Write a payload on the newly create pipe to send to parent:

    const char* kPayload  = "Hello Pipe";
    uv_write_t* w = static_cast<uv_write_t*>(::calloc(1, sizeof(uv_write_t)));
    uv_buf_t buf = uv_buf_init((char*)kPayload, strlen(kPayload));
    uv_write(w, reinterpret_cast<uv_stream_t*>(&pipe_), &buf, 1, onWrite);

This works like a champ on Linux/OSX, however on windows the payload from the child never gets sent. Upon inspection, it appears that on Windows, the child's pipe is being created in non-overlapped mode unless you are in ipc mode trying to copy handles:

from process-stdio.c

        child_pipe = CreateFileA(pipe_name,
                           client_access,
                           0,
                           &sa,
                           OPEN_EXISTING,
                           server_pipe->ipc ? FILE_FLAG_OVERLAPPED : 0,
                           NULL);

This is a problem in the child process as it is emulating overlapped mode by creating worker threads for both ::ReadFile and ::WriteFile (ie. uv_pipe_zero_readfile_thread_proc and uv_pipe_writefile_thread_proc). If both ReadFile and WriteFile are called on the same pipe handle, the result is deadlock.

I was able to work around this by patching the code to create the child's handle using FILE_FLAG_OVERLAPPED when in full duplex mode (see patch below). The patch is not completely satisfying; thoughts on a cleaner solution?

The Patch:

diff --git a/src/win/process-stdio.c b/src/win/process-stdio.c
index 98566da..c0000f7 100644
--- a/src/win/process-stdio.c
+++ b/src/win/process-stdio.c
@@ -101,6 +101,7 @@ static int uv__create_stdio_pipe_pair(uv_loop_t* loop,
   SECURITY_ATTRIBUTES sa;
   DWORD server_access = 0;
   DWORD client_access = 0;
+  DWORD client_flags = 0;
   HANDLE child_pipe = INVALID_HANDLE_VALUE;
   int err;

@@ -117,6 +118,13 @@ static int uv__create_stdio_pipe_pair(uv_loop_t* loop,
     client_access |= GENERIC_WRITE | FILE_READ_ATTRIBUTES;
   }

+  /* If server is in IPC mode, or pipe is full duplex, create the client */
+  /* handle in OVERLAPPED mode.  This will allow the the client to read/write */
+  /* the pipe without blocking in WriteFile() */
+  if (server_pipe->ipc || ((flags & UV_WRITABLE_PIPE) && (flags & UV_READABLE_PIPE))) {
+    client_flags |= FILE_FLAG_OVERLAPPED;
+  }
+
   /* Create server pipe handle. */
   err = uv_stdio_pipe_server(loop,
                              server_pipe,
@@ -136,7 +144,7 @@ static int uv__create_stdio_pipe_pair(uv_loop_t* loop,
                            0,
                            &sa,
                            OPEN_EXISTING,
-                           server_pipe->ipc ? FILE_FLAG_OVERLAPPED : 0,
+                           client_flags,
                            NULL);
   if (child_pipe == INVALID_HANDLE_VALUE) {
     err = GetLastError();

Quick and dirty program demonstrating bug; tested on OSX and Windows.

#include <uv.h>
#include <stdio.h>
#include <stdlib.h>

#if defined(_WIN32)
#include <process.h>
#else
#include <sys/types.h>
#include <unistd.h>
#endif

//*****************************************************************************
// Helpers

int GetPID() {
#if defined(_WIN32)
    return _getpid();
#else
    return getpid();
#endif
}

void OnExit(uv_process_t* process, int64_t exit_status, int term_signal) {
    fprintf(stdout, "[%i] parent on exit status: %lli sig:%i\n", GetPID(), exit_status, term_signal);
}

uv_process_t process_;
uv_pipe_t pipe_;


void onAlloc(uv_handle_t*,
            size_t suggested_size,
            uv_buf_t* buf) 
{
    void* b = ::malloc(suggested_size);
    *buf = uv_buf_init((char*)b, suggested_size);
}

void onRead(uv_stream_t* stream, ssize_t nread, const uv_buf_t* buf) 
{
    if (nread > 0) {
        fprintf(stdout, "[%i] OnRead: ", GetPID());
        fwrite(buf->base, 1, nread, stdout);
        fprintf(stdout, "\n");
    }
}

void onWrite(uv_write_t* req, int status) {
    fprintf(stdout, "[%i] onWrite. stopping loop \n", GetPID());
    free(req);
    uv_stop(uv_default_loop());
}

//*****************************************************************************
// Spawn itself as child process, inheriting stdout for output,
// creating a pipe on stderr to push data back from child process

void doSpawn(char* nm) {
    const char* args[3] = {
        nm,
        "-",
        NULL
    };
    uv_loop_t* loop = uv_default_loop();

    uv_process_options_t uvopts;
    memset(&uvopts, 0, sizeof(uvopts));
    uvopts.file = nm;
    uvopts.exit_cb = OnExit;
    uvopts.args = (char**)args;

    const size_t kNumSlots = 3;
    uv_stdio_container_t slots[kNumSlots];
    for (size_t i=0; i < kNumSlots; ++i) {
        memset(&slots[i], 0, sizeof(uv_stdio_container_t));
        slots[i].flags = UV_IGNORE;
    }

    slots[1].flags = UV_INHERIT_FD;
    slots[1].data.fd = 1;

    uv_pipe_init(loop, &pipe_, 0);
    const int kFlags = UV_CREATE_PIPE  | UV_READABLE_PIPE | UV_WRITABLE_PIPE;
    slots[2].flags = static_cast<uv_stdio_flags>(kFlags);
    slots[2].data.stream = reinterpret_cast<uv_stream_t*>(&pipe_);

    uvopts.stdio_count = static_cast<int>(kNumSlots);
    uvopts.stdio = slots;

    int rval = uv_spawn(loop, &process_, &uvopts);
    fprintf(stdout, "[%i] uv_spawn %i\n", GetPID(), rval);

    uv_read_start(reinterpret_cast<uv_stream_t*>(&pipe_), onAlloc, onRead);

    uv_run(loop, UV_RUN_DEFAULT);

}

//*****************************************************************************
// open the file descriptor in the child process, first writing directly
// later as a pipe.

void doOpen() {

    // writing directly to file descriptor works cool and the gang
    fprintf(stderr, " Hello FD from [%i]", GetPID());

    // opening a pipe in child works as well
    uv_loop_t* loop = uv_default_loop();
    uv_pipe_init(loop, &pipe_, 0);
    int rval = uv_pipe_open(&pipe_, 2);
    fprintf(stdout, "[%i] uv_pipe_open %i\n", GetPID(), rval);

    rval = uv_read_start(reinterpret_cast<uv_stream_t*>(&pipe_), onAlloc, onRead);
    fprintf(stdout, "[%i] read started in child %i\n", GetPID(), rval);

    // writing on the pipe works fine on linux, but freezes on windows:
    uv_write_t* w = static_cast<uv_write_t*>(::calloc(1, sizeof(uv_write_t)));

    const char* kPayload  = "Hello Pipe";
    uv_buf_t buf = uv_buf_init((char*)kPayload, strlen(kPayload));

    fprintf(stdout, "[%i] about to write\n", GetPID());
    uv_write(w, reinterpret_cast<uv_stream_t*>(&pipe_), &buf, 1, onWrite); 
    fprintf(stdout, "[%i] done write %i\n", GetPID(), rval);

    uv_run(loop, UV_RUN_DEFAULT);
}


int main (int argc, char** argv) {
    int rval = 0;
    if (argc == 1) {
        fprintf(stdout, "[%i] in parent\n", GetPID());
        doSpawn(argv[0]);
    } else {
        fprintf(stdout, "[%i] in child\n", GetPID());
        doOpen();
        rval = 1;
    }

    return rval;
}

some test error

=============================================================
[%   9|+  22|-   0|T   0|S   0]: pipe_connect_to_file
`pipe_connect_to_file` failed: exit code 6
Output from process `pipe_connect_to_file`:
Assertion failed in test/test-pipe-connect-error.c on line 53: status == UV_ENOTSOCK || status == UV_ECONNREFUSED
=============================================================
[%  61|+ 148|-   1|T   0|S   0]: getaddrinfo_fail
`getaddrinfo_fail` failed: exit code 6
Output from process `getaddrinfo_fail`:
Assertion failed in test/test-getaddrinfo.c on line 43: status < 0
=============================================================
[%  87|+ 210|-   2|T   0|S   0]: fs_event_watch_file_twice
`fs_event_watch_file_twice` failed: exit code 6
Output from process `fs_event_watch_file_twice`:
Assertion failed in test/test-fs-event.c on line 331: 0 == uv_fs_event_start(watchers + 0, fail_cb, path, 0)
=============================================================
[%  91|+ 220|-   3|T   0|S   0]: fs_scandir_file
`fs_scandir_file` failed: exit code 6
Output from process `fs_scandir_file`:
Assertion failed in test/test-fs.c on line 1938: r == UV_ENOTDIR
=============================================================
[% 100|+ 239|-   4|T   0|S   0]: Done.


Linux lonerwolf-PC 3.13.0-37-generic #64-Ubuntu SMP Mon Sep 22 21:28:38 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

darwin: uv_exepath() fails with UV_EPERM when buffer is too small

To replicate:

diff --git a/test/test-get-currentexe.c b/test/test-get-currentexe.c
index be578db..f97f237 100644
--- a/test/test-get-currentexe.c
+++ b/test/test-get-currentexe.c
@@ -33,6 +33,11 @@ TEST_IMPL(get_currentexe) {
   char* path;
   int r;

+  size = 1;
+  ASSERT(0 == uv_exepath(buffer, &size));
+  ASSERT(0 == buffer[0]);
+  ASSERT(0 == size);
+
   size = sizeof(buffer) / sizeof(buffer[0]);
   r = uv_exepath(buffer, &size);
   ASSERT(!r);

EDIT: It's not a new bug, it was introduced in 2011 in commit c4c022f.

Dr. Memory errors

I just run Dr. Memory against the tests suite on Windows. Here are the results: https://gist.github.com/schlamar/29a9d4be6b061a27dcfa

There are a lot of UNINITIALIZED READ errors which might be false positives but some of the errors (e.g. the leaks) should be valid.

test: fs_event_watch_dir fails on OSX

Thank you for your awesome work guys. 👍

Building @ Darwin, got this error :

deps/libuv [ sh autogen.sh;./configure;make;make check;make install                                                                    master ] 2:54 pm
+ glibtoolize
glibtoolize: putting auxiliary files in `.'.
glibtoolize: linking file `./ltmain.sh'
glibtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.
glibtoolize: linking file `m4/libtool.m4'
glibtoolize: linking file `m4/ltoptions.m4'
glibtoolize: linking file `m4/ltsugar.m4'
glibtoolize: linking file `m4/ltversion.m4'
glibtoolize: linking file `m4/lt~obsolete.m4'
+ aclocal -I m4
+ autoconf
+ automake --add-missing --copy
configure.ac:29: installing './ar-lib'
configure.ac:25: installing './compile'
configure.ac:22: installing './config.guess'
configure.ac:22: installing './config.sub'
configure.ac:21: installing './install-sh'
configure.ac:21: installing './missing'
Makefile.am: installing './depcomp'
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... ./install-sh -c -d
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking build system type... x86_64-apple-darwin13.4.0
checking host system type... x86_64-apple-darwin13.4.0
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking if gcc supports -Wno-dollar-in-identifier-extension flag... yes
checking for ar... ar
checking the archiver (ar) interface... ar
checking whether make supports nested variables... (cached) yes
checking how to print strings... printf
checking for a sed that does not truncate output... /usr/bin/sed
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for fgrep... /usr/bin/grep -F
checking for ld used by gcc... /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld
checking if the linker (/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld) is GNU ld... no
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm
checking the name lister (/usr/bin/nm) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 196608
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking how to convert x86_64-apple-darwin13.4.0 file names to x86_64-apple-darwin13.4.0 format... func_convert_file_noop
checking how to convert x86_64-apple-darwin13.4.0 file names to toolchain format... func_convert_file_noop
checking for /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld option to reload object files... -r
checking for objdump... no
checking how to recognize dependent libraries... pass_all
checking for dlltool... no
checking how to associate runtime and link libraries... printf %s\n
checking for archiver @FILE support... no
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm output from gcc object... ok
checking for sysroot... no
checking for mt... no
checking if : is a manifest tool... no
checking for dsymutil... dsymutil
checking for nmedit... nmedit
checking for lipo... lipo
checking for otool... otool
checking for otool64... no
checking for -single_module linker flag... yes
checking for -exported_symbols_list linker flag... yes
checking for -force_load linker flag... yes
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... yes
checking for gcc option to produce PIC... -fno-common -DPIC
checking if gcc PIC flag -fno-common -DPIC works... yes
checking if gcc static flag -static works... no
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld) supports shared libraries... yes
checking dynamic linker characteristics... darwin13.4.0 dyld
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking for dlopen in -ldl... yes
checking for kstat_lookup in -lkstat... no
checking for kvm_open in -lkvm... no
checking for gethostbyname in -lnsl... no
checking for perfstat_cpu in -lperfstat... no
checking for pthread_mutex_init in -lpthread... yes
checking for clock_gettime in -lrt... no
checking for sendfile in -lsendfile... no
checking for socket in -lsocket... no
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large files... no
checking for pkg-config... yes
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating libuv.pc
config.status: creating Makefile
config.status: executing depfiles commands
config.status: executing libtool commands
  CC       src/libuv_la-fs-poll.lo
  CC       src/libuv_la-inet.lo
  CC       src/libuv_la-threadpool.lo
  CC       src/libuv_la-uv-common.lo
  CC       src/libuv_la-version.lo
  CC       src/unix/libuv_la-async.lo
  CC       src/unix/libuv_la-core.lo
  CC       src/unix/libuv_la-dl.lo
  CC       src/unix/libuv_la-fs.lo
  CC       src/unix/libuv_la-getaddrinfo.lo
  CC       src/unix/libuv_la-getnameinfo.lo
  CC       src/unix/libuv_la-loop-watcher.lo
  CC       src/unix/libuv_la-loop.lo
  CC       src/unix/libuv_la-pipe.lo
  CC       src/unix/libuv_la-poll.lo
  CC       src/unix/libuv_la-process.lo
  CC       src/unix/libuv_la-signal.lo
  CC       src/unix/libuv_la-stream.lo
src/unix/stream.c:1054:19: warning: variable length array folded to constant array as an extension [-Wgnu-folding-constant]
  char cmsg_space[CMSG_SPACE(UV__CMSG_FD_SIZE)];
                  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/sys/socket.h:517:24: note: expanded from macro 'CMSG_SPACE'
#define CMSG_SPACE(l)           (__DARWIN_ALIGN32(sizeof(struct cmsghdr)) + __DARWIN_ALIGN32(l))
                                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/unix/stream.c:1054:19: note: cast that performs the conversions of a reinterpret_cast is not allowed in a constant expression
/usr/include/sys/socket.h:517:25: note: expanded from macro 'CMSG_SPACE'
#define CMSG_SPACE(l)           (__DARWIN_ALIGN32(sizeof(struct cmsghdr)) + __DARWIN_ALIGN32(l))
                                 ^
/usr/include/i386/_param.h:43:42: note: expanded from macro '__DARWIN_ALIGN32'
#define       __DARWIN_ALIGN32(p)       ((__darwin_size_t)((char *)(__darwin_size_t)(p) + __DARWIN_ALIGNBYTES32) &~ __DARWIN_ALIGNBYTES32)
                                         ^
1 warning generated.
  CC       src/unix/libuv_la-tcp.lo
  CC       src/unix/libuv_la-thread.lo
  CC       src/unix/libuv_la-timer.lo
  CC       src/unix/libuv_la-tty.lo
  CC       src/unix/libuv_la-udp.lo
  CC       src/unix/libuv_la-darwin.lo
  CC       src/unix/libuv_la-darwin-proctitle.lo
  CC       src/unix/libuv_la-fsevents.lo
  CC       src/unix/libuv_la-kqueue.lo
  CC       src/unix/libuv_la-proctitle.lo
  CCLD     libuv.la
/Applications/Xcode.app/Contents/Developer/usr/bin/make  test/run-tests
  CC       test/test_run_tests-blackhole-server.o
  CC       test/test_run_tests-dns-server.o
  CC       test/test_run_tests-echo-server.o
  CC       test/test_run_tests-run-tests.o
  CC       test/test_run_tests-runner.o
  CC       test/test_run_tests-test-active.o
  CC       test/test_run_tests-test-async.o
  CC       test/test_run_tests-test-async-null-cb.o
  CC       test/test_run_tests-test-barrier.o
  CC       test/test_run_tests-test-callback-order.o
  CC       test/test_run_tests-test-callback-stack.o
  CC       test/test_run_tests-test-close-fd.o
  CC       test/test_run_tests-test-close-order.o
  CC       test/test_run_tests-test-condvar.o
  CC       test/test_run_tests-test-connection-fail.o
  CC       test/test_run_tests-test-cwd-and-chdir.o
  CC       test/test_run_tests-test-default-loop-close.o
  CC       test/test_run_tests-test-delayed-accept.o
  CC       test/test_run_tests-test-dlerror.o
  CC       test/test_run_tests-test-embed.o
  CC       test/test_run_tests-test-emfile.o
  CC       test/test_run_tests-test-error.o
  CC       test/test_run_tests-test-fail-always.o
  CC       test/test_run_tests-test-fs-event.o
  CC       test/test_run_tests-test-fs-poll.o
  CC       test/test_run_tests-test-fs.o
  CC       test/test_run_tests-test-get-currentexe.o
  CC       test/test_run_tests-test-get-loadavg.o
  CC       test/test_run_tests-test-get-memory.o
  CC       test/test_run_tests-test-getaddrinfo.o
  CC       test/test_run_tests-test-getnameinfo.o
  CC       test/test_run_tests-test-getsockname.o
  CC       test/test_run_tests-test-handle-fileno.o
  CC       test/test_run_tests-test-hrtime.o
  CC       test/test_run_tests-test-idle.o
  CC       test/test_run_tests-test-ip4-addr.o
  CC       test/test_run_tests-test-ip6-addr.o
  CC       test/test_run_tests-test-ipc-send-recv.o
  CC       test/test_run_tests-test-ipc.o
  CC       test/test_run_tests-test-loop-handles.o
  CC       test/test_run_tests-test-loop-alive.o
  CC       test/test_run_tests-test-loop-close.o
  CC       test/test_run_tests-test-loop-stop.o
  CC       test/test_run_tests-test-loop-time.o
  CC       test/test_run_tests-test-multiple-listen.o
  CC       test/test_run_tests-test-mutexes.o
  CC       test/test_run_tests-test-osx-select.o
  CC       test/test_run_tests-test-pass-always.o
  CC       test/test_run_tests-test-ping-pong.o
  CC       test/test_run_tests-test-pipe-bind-error.o
  CC       test/test_run_tests-test-pipe-connect-error.o
  CC       test/test_run_tests-test-pipe-getsockname.o
  CC       test/test_run_tests-test-pipe-sendmsg.o
  CC       test/test_run_tests-test-pipe-server-close.o
  CC       test/test_run_tests-test-pipe-close-stdout-read-stdin.o
  CC       test/test_run_tests-test-platform-output.o
  CC       test/test_run_tests-test-poll-close.o
  CC       test/test_run_tests-test-poll-closesocket.o
  CC       test/test_run_tests-test-poll.o
  CC       test/test_run_tests-test-process-title.o
  CC       test/test_run_tests-test-ref.o
  CC       test/test_run_tests-test-run-nowait.o
  CC       test/test_run_tests-test-run-once.o
  CC       test/test_run_tests-test-semaphore.o
  CC       test/test_run_tests-test-shutdown-close.o
  CC       test/test_run_tests-test-shutdown-eof.o
  CC       test/test_run_tests-test-shutdown-twice.o
  CC       test/test_run_tests-test-signal-multiple-loops.o
  CC       test/test_run_tests-test-signal.o
  CC       test/test_run_tests-test-socket-buffer-size.o
  CC       test/test_run_tests-test-spawn.o
  CC       test/test_run_tests-test-stdio-over-pipes.o
  CC       test/test_run_tests-test-tcp-bind-error.o
  CC       test/test_run_tests-test-tcp-bind6-error.o
  CC       test/test_run_tests-test-tcp-close-accept.o
  CC       test/test_run_tests-test-tcp-close-while-connecting.o
  CC       test/test_run_tests-test-tcp-close.o
  CC       test/test_run_tests-test-tcp-connect-error-after-write.o
  CC       test/test_run_tests-test-tcp-connect-error.o
  CC       test/test_run_tests-test-tcp-connect-timeout.o
  CC       test/test_run_tests-test-tcp-connect6-error.o
  CC       test/test_run_tests-test-tcp-flags.o
  CC       test/test_run_tests-test-tcp-open.o
  CC       test/test_run_tests-test-tcp-read-stop.o
  CC       test/test_run_tests-test-tcp-shutdown-after-write.o
  CC       test/test_run_tests-test-tcp-unexpected-read.o
  CC       test/test_run_tests-test-tcp-write-to-half-open-connection.o
  CC       test/test_run_tests-test-tcp-write-after-connect.o
  CC       test/test_run_tests-test-tcp-writealot.o
  CC       test/test_run_tests-test-tcp-try-write.o
  CC       test/test_run_tests-test-tcp-write-queue-order.o
  CC       test/test_run_tests-test-thread-equal.o
  CC       test/test_run_tests-test-thread.o
  CC       test/test_run_tests-test-threadpool-cancel.o
  CC       test/test_run_tests-test-threadpool.o
  CC       test/test_run_tests-test-timer-again.o
  CC       test/test_run_tests-test-timer-from-check.o
  CC       test/test_run_tests-test-timer.o
  CC       test/test_run_tests-test-tty.o
  CC       test/test_run_tests-test-udp-bind.o
  CC       test/test_run_tests-test-udp-dgram-too-big.o
  CC       test/test_run_tests-test-udp-ipv6.o
  CC       test/test_run_tests-test-udp-multicast-interface.o
  CC       test/test_run_tests-test-udp-multicast-interface6.o
  CC       test/test_run_tests-test-udp-multicast-join.o
  CC       test/test_run_tests-test-udp-multicast-join6.o
  CC       test/test_run_tests-test-udp-multicast-ttl.o
  CC       test/test_run_tests-test-udp-open.o
  CC       test/test_run_tests-test-udp-options.o
  CC       test/test_run_tests-test-udp-send-and-recv.o
  CC       test/test_run_tests-test-udp-send-immediate.o
  CC       test/test_run_tests-test-udp-send-unreachable.o
  CC       test/test_run_tests-test-udp-try-send.o
  CC       test/test_run_tests-test-walk-handles.o
  CC       test/test_run_tests-test-watcher-cross-stop.o
  CC       test/test_run_tests-runner-unix.o
  CCLD     test/run-tests
/Applications/Xcode.app/Contents/Developer/usr/bin/make  check-TESTS
[%   0|+   0|-   0|T   0|S   0]: platform_output
Output from process `platform_output`:
uv_get_process_title: /Users/hems/git/loopcast/appcast/Appcast/deps/libuv/test/.libs/run-tests
uv_resident_set_memory: 593920
uv_uptime: 416572.000000
uv_getrusage:
  user: 0 sec 972 microsec
  system: 0 sec 1109 microsec
uv_cpu_info:
  model: Intel(R) Core(TM) i7-2635QM CPU @ 2.00GHz
  speed: 2000
  times.sys: 35976870
  times.user: 69336390
  times.idle: 165557690
  times.irq: 0
  times.nice: 0
  model: Intel(R) Core(TM) i7-2635QM CPU @ 2.00GHz
  speed: 2000
  times.sys: 6551090
  times.user: 42575950
  times.idle: 221250190
  times.irq: 0
  times.nice: 0
  model: Intel(R) Core(TM) i7-2635QM CPU @ 2.00GHz
  speed: 2000
  times.sys: 17615010
  times.user: 56376690
  times.idle: 196385620
  times.irq: 0
  times.nice: 0
  model: Intel(R) Core(TM) i7-2635QM CPU @ 2.00GHz
  speed: 2000
  times.sys: 4817910
  times.user: 40160400
  times.idle: 225398880
  times.irq: 0
  times.nice: 0
  model: Intel(R) Core(TM) i7-2635QM CPU @ 2.00GHz
  speed: 2000
  times.sys: 15460210
  times.user: 52943520
  times.idle: 201973560
  times.irq: 0
  times.nice: 0
  model: Intel(R) Core(TM) i7-2635QM CPU @ 2.00GHz
  speed: 2000
  times.sys: 4316560
  times.user: 39211610
  times.idle: 226849000
  times.irq: 0
  times.nice: 0
  model: Intel(R) Core(TM) i7-2635QM CPU @ 2.00GHz
  speed: 2000
  times.sys: 14397410
  times.user: 51247620
  times.idle: 204732230
  times.irq: 0
  times.nice: 0
  model: Intel(R) Core(TM) i7-2635QM CPU @ 2.00GHz
  speed: 2000
  times.sys: 4071700
  times.user: 38768140
  times.idle: 227537290
  times.irq: 0
  times.nice: 0
uv_interface_addresses:
  name: lo0
  internal: 1
  physical address: 00:00:00:00:00:00
  address: ::1
  netmask: ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff
  name: lo0
  internal: 1
  physical address: 00:00:00:00:00:00
  address: 127.0.0.1
  netmask: 255.0.0.0
  name: lo0
  internal: 1
  physical address: 00:00:00:00:00:00
  address: fe80::1
  netmask: ffff:ffff:ffff:ffff::
  name: en1
  internal: 0
  physical address: e0:f8:47:43:8f:6c
  address: fe80::e2f8:47ff:fe43:8f6c
  netmask: ffff:ffff:ffff:ffff::
  name: en1
  internal: 0
  physical address: e0:f8:47:43:8f:6c
  address: 192.168.0.2
  netmask: 255.255.255.0
=============================================================
[%  72|+ 177|-   0|T   0|S   0]: spawn_reads_child_path
`spawn_reads_child_path` failed: exit code 6
Output from process `spawn_reads_child_path`:
exit_cb
Assertion failed in test/test-spawn.c on line 66: exit_status == 1
=============================================================
[%  77|+ 188|-   1|T   0|S   0]: osx_selectgot some input
with a couple of lines
feel pretty happy
[%  77|+ 189|-   1|T   0|S   0]: osx_select_many_fdsgot some input
with a couple of lines
feel pretty happy
[%  86|+ 211|-   1|T   0|S   0]: fs_event_watch_dir
`fs_event_watch_dir` failed: timeout
Output from process `fs_event_watch_dir`: (no output)
=============================================================
[% 100|+ 243|-   2|T   0|S   0]: Done.
FAIL: test/run-tests
======================================================
1 of 1 test failed
Please report to https://github.com/libuv/libuv/issues
======================================================
make[1]: *** [check-TESTS] Error 1
make: *** [check-am] Error 2
 ./install-sh -c -d '/usr/local/lib'
 /bin/sh ./libtool   --mode=install /usr/bin/install -c   libuv.la '/usr/local/lib'
libtool: install: /usr/bin/install -c .libs/libuv.1.dylib /usr/local/lib/libuv.1.dylib
libtool: install: (cd /usr/local/lib && { ln -s -f libuv.1.dylib libuv.dylib || { rm -f libuv.dylib && ln -s libuv.1.dylib libuv.dylib; }; })
libtool: install: /usr/bin/install -c .libs/libuv.lai /usr/local/lib/libuv.la
libtool: install: /usr/bin/install -c .libs/libuv.a /usr/local/lib/libuv.a
libtool: install: chmod 644 /usr/local/lib/libuv.a
libtool: install: ranlib /usr/local/lib/libuv.a
 ./install-sh -c -d '/usr/local/include'
 /usr/bin/install -c -m 644 include/uv.h include/uv-errno.h include/uv-threadpool.h include/uv-version.h include/uv-unix.h include/uv-darwin.h '/usr/local/include'
 ./install-sh -c -d '/usr/local/lib/pkgconfig'
 /usr/bin/install -c -m 644 libuv.pc '/usr/local/lib/pkgconfig'
deps/libuv [                                                                                                                           master ] 2:57 pm

Thread pool for Linux file I/O a bad idea?

I was just thinking about this... maybe the thread pool in libuv isn't the answer for file IO and DNS lookup operations in Linux.

@indutny - As you mentioned here (joyent/libuv#1181), the thread pool can fill with requests quite easily, especially when getaddrinfo is being called during periods of poor network connectivity. Suddenly, applications using libuv (i.e. Node) can become completely unresponsive. If the application needs to have somewhat real-time access to other I/O (i.e. reading/writing a file before a certain amount of time expires), the wheels start to fall off.

Consider an HTTP web server that's about to experience some network difficulty, for example. Suppose you enforce a time limit for requests (even as little as 100 ms) to serve mostly static HTML files. If you have other HTTP requests that perform DNS lookups (i.e. your web server also serves as a proxy), you can potentially fill the thread queue with getaddrinfo requests and cause a lot of HTTP requests to fail. That is, since the thread queue is filled with slow DNS requests, the server can't even read the static HTML files from the disk and serve its other requests. Timeouts occur, and the server becomes unresponsive.

Also consider an application that reads data from a serial port and sends the data to a remote server. If DNS requests to the remote server clog up the thread pool, the serial port read operation might not happen in time (the OS internal buffers could start to fill up and overflow).

That said, I understand that non-blocking file I/O in Linux is a pain in the rear. I'd be happy to take this conversation offline, but are there any thoughts on moving forward?

CI infrastructure

Now that we are flying solo we'll need a CI infrastrucre to test libuv. @rvagg, you were working on that for node-forward, right? Would it be possible for libuv to use it?

cfmakeraw() in uv_tty_set_mode() causing downstream issues

0f25560, specifically related to c_oflag, appears to be the cause of nodejs/node-v0.x-archive#8817.

Linking to the original libuv PR, which has some additional info.

cc: @bnoordhuis

[2.0 RFC] "pull based" event loop

EDIT: the proposal is now here: libuv/leps#3

Please read the README for information on the LEP process: https://github.com/libuv/leps/blob/master/README.md

[2.0 RFC] Thread pool handle

EDIT: the proposal is now here: libuv/leps#4

Please read the README for information on the LEP process: https://github.com/libuv/leps/blob/master/README.md

Fix uv_tty_set_mode / use cfmakeraw() when available.

The uv_tty_set_mode(tty, 1) should switch to raw mode, but currently doesn't set all the required flags. The resulting TTY is still not suitable for binary I/O.

There is already a patch for this:

joyent/libuv@0f25560

however see the existing discussion at the old PR: joyent/libuv#1567

I believe iojs is at fault here, though I'll bend over and introduce a new tty "mode" (2) to allow binary I/O if required.

Test failing on OSX

Master branch:

=============================================================
[%  58|+ 144|-   0|T   0|S   0]: cwd_and_chdir
`cwd_and_chdir` failed: exit code 6
Output from process `cwd_and_chdir`:
Assertion failed in test/test-cwd-and-chdir.c on line 63: size1 == size2
=============================================================

Prepare next release: 1.1.1

I don't have anything pending for making a new release, let's make one :-)

Any objections @bnoordhuis, @piscisaureus ?

tests failing on OS X

=============================================================
[%  57|+ 142|-   0|T   0|S   0]: get_currentexe
`get_currentexe` failed: exit code 6
Output from process `get_currentexe`:
Assertion failed in test/test-get-currentexe.c on line 53: match && !strcmp(match, path)
=============================================================
[%  72|+ 176|-   1|T   0|S   0]: spawn_reads_child_path
`spawn_reads_child_path` failed: exit code 6
Output from process `spawn_reads_child_path`:
exit_cb
Assertion failed in test/test-spawn.c on line 66: exit_status == 1
=============================================================
[%  77|+ 187|-   2|T   0|S   0]: osx_selectgot some input
with a couple of lines
feel pretty happy
[%  77|+ 188|-   2|T   0|S   0]: osx_select_many_fds
`osx_select_many_fds` failed: exit code 6
Output from process `osx_select_many_fds`:
Assertion failed in test/test-osx-select.c on line 100: r == 0
=============================================================
[%  90|+ 219|-   3|T   0|S   0]: fs_event_error_reporting
`fs_event_error_reporting` failed: exit code 6
Output from process `fs_event_error_reporting`:
Assertion failed in test/test-fs-event.c on line 711: 0 == uv_fs_event_start(event, fs_event_error_report_cb, "watch_dir", 0)
=============================================================
[% 100|+ 241|-   4|T   0|S   0]: Done.
FAIL: test/run-tests
======================================================
1 of 1 test failed
Please report to https://github.com/libuv/libuv/issues
======================================================
make[1]: *** [check-TESTS] Error 1
make: *** [check-am] Error 2

make test failed osx

failed using autogen.sh .. will try GYP next.

=============================================================
[%  72|+ 178|-   0|T   0|S   0]: spawn_reads_child_path
`spawn_reads_child_path` failed: exit code 6
Output from process `spawn_reads_child_path`:
exit_cb
Assertion failed in test/test-spawn.c on line 66: exit_status == 1
=============================================================
[%  77|+ 189|-   1|T   0|S   0]: osx_selectgot some input
with a couple of lines
feel pretty happy
[%  77|+ 190|-   1|T   0|S   0]: osx_select_many_fdsgot some input
with a couple of lines
feel pretty happy
[% 100|+ 245|-   1|T   0|S   0]: Done.
FAIL: test/run-tests
======================================================
1 of 1 test failed
Please report to https://github.com/libuv/libuv/issues
======================================================
make[1]: *** [check-TESTS] Error 1
make: *** [check-am] Error 2

Add OS info preceding tests

Currently, interface and cpu/memory information precedes test output. In order to simplify submitting test failures, the info could benefit from os/architecture information as well (see for instance #30).

Another option would be writing fail output and a summary to a markdown document for easier pasting. Come to think of it, this sounds like a pretty nifty C library :)

Feature request: sigqueue

In linux, sigqueue can send signal with attached data.

linux: epoll_pwait() syscall wrapper is probably wrong

It currently passes sizeof(sigset_t) to the kernel but that's wrong on at least x86_64. A patch:

diff --git a/src/unix/linux-syscalls.c b/src/unix/linux-syscalls.c
index 06cc594..ee90b84 100644
--- a/src/unix/linux-syscalls.c
+++ b/src/unix/linux-syscalls.c
@@ -21,6 +21,7 @@

 #include "linux-syscalls.h"
 #include <unistd.h>
+#include <signal.h>
 #include <sys/syscall.h>
 #include <sys/types.h>
 #include <errno.h>
@@ -298,7 +299,7 @@ int uv__epoll_pwait(int epfd,
                  nevents,
                  timeout,
                  sigmask,
-                 sizeof(*sigmask));
+                 _NSIG / 8);
 #else
   return errno = ENOSYS, -1;
 #endif

_NSIG / 8 is 8, whereas sizeof(*sigmask) is 128 and makes the system call fail with EINVAL. I'm reasonably sure that the above is correct (it's how glibc implements epoll_wait) but it perhaps needs some additional verification.