f6422af80a
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.
|
||
|---|---|---|
| include | ||
| src | ||
| test | ||
| .gitignore | ||
| .mailmap | ||
| AUTHORS | ||
| build.mk | ||
| ChangeLog | ||
| checksparse.sh | ||
| common.gypi | ||
| config-mingw.mk | ||
| config-unix.mk | ||
| gyp_uv.py | ||
| LICENSE | ||
| Makefile | ||
| README.md | ||
| uv.gyp | ||
| vcbuild.bat | ||
libuv
libuv is a new platform layer for Node. Its purpose is to abstract IOCP on Windows and epoll/kqueue/event ports/etc. on Unix systems. We intend to eventually contain all platform differences in this library.
Features
-
Non-blocking TCP sockets
-
Non-blocking named pipes
-
UDP
-
Timers
-
Child process spawning
-
Asynchronous DNS via
uv_getaddrinfo. -
Asynchronous file system APIs
uv_fs_* -
High resolution time
uv_hrtime -
Current executable path look up
uv_exepath -
Thread pool scheduling
uv_queue_work -
ANSI escape code controlled TTY
uv_tty_t -
File system events Currently supports inotify,
ReadDirectoryChangesWand kqueue. Event ports in the near future.uv_fs_event_t -
IPC and socket sharing between processes
uv_write2
Community
Documentation
- include/uv.h — API documentation in the form of detailed header comments.
- An Introduction to libuv — An overview of libuv with tutorials.
- LXJS 2012 talk - High-level introductory talk about libuv.
- Tests and benchmarks - API specification and usage examples.
Build Instructions
For GCC (including MinGW) there are two methods building: via normal makefiles or via GYP. GYP is a meta-build system which can generate MSVS, Makefile, and XCode backends. It is best used for integration into other projects. The old system is using plain GNU Makefiles.
To build via Makefile simply execute:
make
MinGW users should run this instead:
make PLATFORM=mingw
Out-of-tree builds are supported:
make builddir_name=/path/to/builddir
To build with Visual Studio run the vcbuild.bat file which will checkout the GYP code into build/gyp and generate the uv.sln and related files.
Windows users can also build from cmd-line using msbuild. This is done by running vcbuild.bat from Visual Studio command prompt.
To have GYP generate build script for another system, make sure that you have Python 2.6 or 2.7 installed, then checkout GYP into the project tree manually:
mkdir -p build
svn co http://gyp.googlecode.com/svn/trunk build/gyp
Or:
mkdir -p build
git clone https://git.chromium.org/external/gyp.git build/gyp
Unix users run
./gyp_uv.py -f make
make -C out
Macintosh users run
./gyp_uv.py -f xcode
xcodebuild -project uv.xcodeproj -configuration Release -target All
Note for UNIX users: compile your project with -D_LARGEFILE_SOURCE and
-D_FILE_OFFSET_BITS=64. GYP builds take care of that automatically.
Note for Linux users: compile your project with -D_GNU_SOURCE when you
include uv.h. GYP builds take care of that automatically. If you use
autotools, add a AC_GNU_SOURCE declaration to your configure.ac.
Supported Platforms
Microsoft Windows operating systems since Windows XP SP2. It can be built with either Visual Studio or MinGW.
Linux 2.6 using the GCC toolchain.
MacOS using the GCC or XCode toolchain.
Solaris 121 and later using GCC toolchain.