* npm: Upgrade to 1.1.66 (isaacs)
* linux: use /proc/cpuinfo for CPU frequency (Ben Noordhuis)
* windows: map WSAESHUTDOWN to UV_EPIPE (Ben Noordhuis)
* windows: map ERROR_GEN_FAILURE to UV_EIO (Bert Belder)
* unix: do not set environ unless one is provided (Charlie McConnell)
* domains: don't crash if domain is set to null (Bert Belder)
* windows: fix the x64 debug build (Bert Belder)
* net, tls: fix connect() resource leak (Ben Noordhuis)
OR'ing together two large values, like `SSL_OP_ALL | SSL_OP_NO_TICKET`,
produces a negative number. To wit:
assert((0x80000000 | 0x4000) === -0x7fffc000); // true
assert((0x80000000 | 0x4000) === 0x80004000); // false!
It's easy to work around by doing a logical shift, like this:
assert((0x80000000 | 0x4000) >>> 0 === 0x80004000); // true
But that's not very intuitive. Let's be more lenient in what we accept.
The purpose of this file was to remap the old libeio API to the new one.
We dropped libeio in ee77a6a and this file has been broken ever since.
Ergo, remove it.
* Added isIP method to make use of inet_pton to cares_wrap.cc
* Modified net.isIP() to make use of new C++ isIP method.
* Added new tests to test-net-isip.js.
Inform V8 that the zlib context object is tied to a large off-heap buffer.
This makes the GC run more often (in theory) and improves the accuracy of
--trace_external_memory.
In zlibBuffer(), don't wait for the garbage collector to reclaim the zlib memory
but release it manually. Reduces memory consumption by a factor of 10 or more
with some workloads.
Test case:
function f() {
require('zlib').deflate('xxx', g);
}
function g() {
setTimeout(f, 5);
}
f();
Observe RSS memory usage with and without this commit. After 10,000 iterations,
RSS stabilizes at ~35 MB with this commit. Without, RSS is over 300 MB and keeps
growing.
Cause: whenever the JS object heap hits the high-water mark, the V8 GC sweeps
it clean, then tries to grow it in order to avoid more sweeps in the near
future. Rule of thumb: the bigger the JS heap, the lazier the GC can be.
A side effect of a bigger heap is that objects now live longer. This is harmless
in general but it affects zlib context objects because those are tied to large
buffers that live outside the JS heap, on the order of 16K per context object.
Ergo, don't wait for the GC to reclaim the memory - it may take a long time.
Fixes#4172.
* V8: Upgrade to 3.11.10.25
* npm: Upgrade to 1.1.65
* url: parse hostnames that start with - or _ (Ben Noordhuis)
* repl: Fix Windows 8 terminal issue (Bert Belder)
* typed arrays: use signed char for signed int8s (Aaron Jacobs)
* crypto: fix bugs in DiffieHellman (Ben Noordhuis)
* configure: turn on VFPv3 on ARMv7 (Ben Noordhuis)
* Re-enable OpenSSL UI for entering passphrases via tty (Ben Noordhuis)
* repl: ensure each REPL instance gets its own "context" (Nathan Rajlich)
Fix a use-after-free bug and a memory leak in the error path of
DiffieHellman::ComputeSecret().
* the BIGNUM key was used after being freed with BN_free().
* the output buffer was not freed
Make buffers report the proper retained size in heap snapshots.
Before this commit, Buffer objects would show up in the heap profiler as being
only a few hundred bytes large, even if the actual buffer was many megabytes.
isaacs
Ben Noordhuis
Scott Blomquist
Sergey Kholodilov
Bert Belder
Nathan Rajlich
Joshua Erickson
Anthony Pesch
Jan Wynholds
Aaron Jacobs
Dean McNamee
Andrew Paprocki
koichik
Fedor Indutny