* openssl: to 1.0.1h (CVE-2014-0224)
* npm: upgrade to 1.4.10
* utf8: Prevent Node from sending invalid UTF-8 (Felix Geisendörfer)
- *NOTE* this introduces a breaking change, previously you could construct
invalid UTF-8 and invoke an error in a client that was expecting valid
UTF-8, now unmatched surrogate pairs are replaced with the unknown UTF-8
character. To restore the old functionality simply have NODE_INVALID_UTF8
environment variable set.
* child_process: do not set args before throwing (Greg Sabia Tucker)
* child_process: spawn() does not throw TypeError (Greg Sabia Tucker)
* constants: export O_NONBLOCK (Fedor Indutny)
* crypto: improve memory usage (Alexis Campailla)
* fs: close file if fstat() fails in readFile() (cjihrig)
* lib: name EventEmitter prototype methods (Ben Noordhuis)
* tls: fix performance issue (Alexis Campailla)
Previously we were only shifting the address space for ASLR on 32bit
processes, apply the same shift for 64bit so processes don't
get artificially limited native heap.
Previously v8's WriteUtf8 function would produce invalid utf-8 output
when encountering unmatched surrogate code units [1]. The new
REPLACE_INVALID_UTF8 option fixes that by replacing invalid code points
with the unicode replacement character.
[1]: JS Strings are defined as arrays of 16 bit unsigned integers. There
is no unicode enforcement, so one can easily end up with invalid unicode
code unit sequences inside a string.
- https://codereview.chromium.org/121173009/
- https://code.google.com/p/v8/source/detail?r=18683
Note: The v8 test case did not cleanly apply, so it's missing from this
patch. I'm assuming this is not a problem if the v8 test suite is not
part of the node build / test system. If that's the case I'll fix it.
Otherwise the test case will be integrated once v8 is upgraded.
This patch simplifies the implementation of StringDecoder, fixes the
failures from the new test cases, and also no longer relies on v8's
WriteUtf8 function to encode individual surrogates.
The test cases are still essentially the same, but now all possible ways
of writing a buffer into the decoder are tested, which has exposed a few
failing scenarios that had not been discovered so far!
Currently, if fstat() fails in readFile(), the callback
is invoked without closing the file. This commit closes
the file before calling back.
Closes#7697
Slashes should be documented, because 3rd-party protocols -- those
postfixed with `://` -- would incorrectly `format` and `parse` if they
didn't set/get the `slashes` option.
Signed-off-by: Timothy J Fontaine <tjfontaine@gmail.com>
Adds a section to the transform stream docs to clarify the
difference between the `end` event and the `finish` events.
Also clarifies the wording on the `end` event.
ClientHelloParser used to contain an 18k buffer that was kept around
for the life of the connection, even though it was not needed in many
situations. I changed it to be deallocated when it's determined to
be no longer needed.
Signed-off-by: Fedor Indutny <fedor@indutny.com>
Fix the following compiler warning on systems where _XOPEN_SOURCE is
defined by default:
../src/node_constants.cc:35:0: warning: "_XOPEN_SOURCE" redefined
#define _XOPEN_SOURCE 500
Move the (re)definition of _XOPEN_SOURCE to the top of the file while
we're here. Commit 00890e4 adds a `#define _XOPEN_SOURCE 500` in order
to make <fcntl.h> expose O_NONBLOCK but it does so after other system
headers have been included. If those headers include <fcntl.h>, then
the #include in node_constants.cc will be a no-op and O_NONBLOCK won't
be visible.
Signed-off-by: Fedor Indutny <fedor@indutny.com>
Ensure TypeError is thrown, fix a bug where `env` option was
assuming the option was actually an object.
This case is especially bad because it then sets `env == null`
instead of using `process.env`.
Fix#7456
Signed-off-by: Fedor Indutny <fedor@indutny.com>
Before this commit the EventEmitter methods were anonymous functions.
V8 tries to infer names for anonymous functions based on the execution
context but it frequently gets it wrong and when that happens, the
stack trace is usually confusing and unhelpful. This commit names all
methods so V8 can fall back to the method.name property.
The above gotcha applies to all anonymous functions but is exacerbated
for EventEmitter methods because those are invoked with a plenitude of
different receivers.
Signed-off-by: Trevor Norris <trev.norris@gmail.com>
* Don't set referer if already set
* fetch: Send referer and npm-session headers
* run-script: Support --parseable and --json
* list runnable scripts (Evan Lucas)
* Use marked instead of ronn for html docs
* Check SHA before using files from cache
* adduser: allow change of the saved password
* Make `npm install` respect `config.unicode`
* Fix lifecycle to pass `Infinity` for config env value
* Don't return 0 exit code on invalid command
* cache: Handle 404s and other HTTP errors as errors
* bump tap dep, make tests stderr a bit quieter
* Resolve ~ in path configs to env.HOME
* Include npm version in default user-agent conf
* npm init: Use ISC as default license, use save-prefix for deps
* Many test and doc fixes
Commit f9ced08 switches V8 on Linux over from gettimeofday() to
clock_getres() and clock_gettime(). As of glibc 2.17, those functions
live in libc. For older versions, we need to pull them in from librt.
Fixes the following link-time error;
Release/obj.target/deps/v8/tools/gyp/libv8_base.a(platform-posix.o):
In function `v8::internal::OS::Ticks()':
platform-posix.cc:(.text+0x93c):
undefined reference to `clock_gettime'
platform-posix.cc:(.text+0x989):
undefined reference to `clock_getres'
Fixes#7514.
Signed-off-by: Fedor Indutny <fedor@indutny.com>
Date.now() indirectly calls gettimeofday() on Linux and that's a system
call that is extremely expensive on virtualized systems when the host
operating system has to emulate access to the hardware clock.
Case in point: output from `perf record -c 10000 -e cycles:u -g -i`
for a benchmark/http_simple bytes/8 benchmark with a light load of
50 concurrent clients:
53.69% node node [.] v8::internal::OS::TimeCurrentMillis()
|
--- v8::internal::OS::TimeCurrentMillis()
|
|--99.77%-- v8::internal::Runtime_DateCurrentTime(v8::internal::Arguments, v8::internal::Isolate*)
| 0x23587880618e
That's right - over half of user time spent inside the V8 function that
calls gettimeofday().
Notably, nearly all system time gets attributed to acpi_pm_read(), the
kernel function that reads the ACPI power management timer:
32.49% node [kernel.kallsyms] [k] acpi_pm_read
|
--- acpi_pm_read
|
|--98.40%-- __getnstimeofday
| getnstimeofday
| |
| |--71.61%-- do_gettimeofday
| | sys_gettimeofday
| | system_call_fastpath
| | 0x7fffbbaf6dbc
| | |
| | |--98.72%-- v8::internal::OS::TimeCurrentMillis()
The cost of the gettimeofday() system call is normally measured in
nanoseconds but we were seeing 100 us averages and spikes >= 1000 us.
The numbers were so bad, my initial hunch was that the node process was
continuously getting rescheduled inside the system call...
v8::internal::OS::TimeCurrentMillis()'s most frequent caller is
v8::internal::Runtime_DateCurrentTime(), the V8 run-time function
that's behind Date.now(). The timeout handling logic in lib/http.js
and lib/net.js calls into lib/timers.js and that module will happily
call Date.now() hundreds or even thousands of times per second.
If you saw exports._unrefActive() show up in --prof output a lot,
now you know why.
That's why this commit makes V8 switch over to clock_gettime() on Linux.
In particular, it checks if CLOCK_REALTIME_COARSE is available and has
a resolution <= 1 ms because in that case the clock_gettime() call can
be fully serviced from the vDSO.
It speeds up the aforementioned benchmark by about 100% on the affected
systems and should go a long way toward addressing the latency issues
that StrongLoop customers have been reporting.
This patch will be upstreamed as a CR against V8 3.26. I'm sending it
as a pull request for v0.10 first because that's what our users are
running and because the delta between 3.26 and 3.14 is too big to
reasonably back-port the patch. I'll open a pull request for the
master branch once the CR lands upstream.
Signed-off-by: Trevor Norris <trev.norris@gmail.com>
Signed-off-by: Fedor Indutny <fedor@indutny.com>
* isaacs, Robert Kowalski, Benjamin Coe: Test Improvements
* isaacs doc: Add canonical url
* isaacs view: handle unpublished packages properly
* Raynos (Jake Verbaten) do not log if silent
* Julian Gruber fix no such property error
* isaacs npmconf@0.1.14
* Thorsten Lorenz adding save-prefix configuration option
* isaacs npm-registry-client@0.4.7
* isaacs cache: treat missing versions as a 404
* isaacs cache: Save shasum, write resolved/etc data to cache
* isaacs cache: Always fetch root doc
* isaacs cache: don't repack unnecessarily from tmp
* Andrey Kislyuk Don't crash if shrinkwrap-dependencies were not passed in pkginfo
* Robert Kowalski fix link in faq
* Jean Lauliac Add a peerDependencies section in package.json doc
* isaacs read-installed@2.0.2
Fix possible deadlock, when handles are sent in both direction
simultaneously. In such rare cases, both sides may queue their
`NODE_HANDLE_ACK` replies and wait for them.
fix#7465
`process.uptime()` interface will return the amount of time the
current process has been running. To achieve this it was caching the
`uv_uptime` value at program start, and then on the call to
`process.uptime()` returning the delta between the two values.
`uv_uptime` is defined as the number of seconds the operating system
has been up since last boot. On sunos this interface uses `kstat`s
which can be a significantly expensive operation as it requires
exclusive access, but because of the design of `process.uptime()` node
*had* to always call this on start. As a result if you had many node
processes all starting at the same time you would suffer lock
contention as they all tried to read kstats.
Instead of using `uv_uptime` to achieve this, the libuv loop already
has a concept of current loop time in the form of `uv_now()` which is
in fact monotonically increasing, and already stored directly on the
loop. By using this value at start every platform performs at least
one fewer syscall during initialization.
Since the interface to `uv_uptime` is defined as seconds, in the call
to `process.uptime()` we now `uv_update_time` get our delta, divide by
1000 to get seconds, and then convert to an `Integer`. In 0.12 we can
move back to `Number::New` instead and not lose precision.
Caveat: For some platforms `uv_uptime` reports time monotonically
increasing regardless of system hibernation, `uv_now` interface is
also monotonically increasing but may not reflect time spent in
hibernation.