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.
- 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.
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>
Fix the following valgrind warning:
Conditional jump or move depends on uninitialised value(s)
at 0x7D64E7: v8::internal::GlobalHandles::IterateAllRootsWithClassIds(v8::internal::ObjectVisitor*) (global-handles.cc:613)
by 0x94DCDC: v8::internal::NativeObjectsExplorer::FillRetainedObjects() (profile-generator.cc:2849)
# etc.
This was fixed upstream in r12903 and released in 3.15.2 but that commit
was never back-ported to the 3.14 branch that node.js v0.10 uses.
The code itself works okay; this commit simply shuffles the clauses in
an `if` statement to check that the node is in use before checking its
class id (which is uninitialized if the node is not in use.)
Original commit message:
VS2013 contains a number of improvements, most notably the addition
of all C99 math functions.
I'm a little bit concerned about the change I had to make in
cpu-profiler.cc, but I spent quite a bit of time looking at it and was
unable to figure out any rational explanation for the warning. It's
possible it's spurious. Since it seems like a useful warning in
general though, I chose not to disable globally at the gyp level.
I do think someone with expertise here should probably try to
determine if this is a legitimate warning.
BUG=288948
R=dslomov@chromium.org
Review URL: https://codereview.chromium.org/23449035
NOTE: Path applied without `cpu-profiler.cc` changes because in our
version it was looking totally different.
The %p is replaced with the current PID. This used to work in node.js
v0.9.7 but it seems to have been lost somewhere along the way.
This commit makes the fix from 6b713b52 ("cluster: make --prof work for
workers") work again. Without it, all log data ends up in a single
file and is unusable because the addresses are all wrong.
Quoting CVE-2013-6639:
The DehoistArrayIndex function in hydrogen-dehoist.cc in Google V8
before 3.22.24.7, as used in Google Chrome before 31.0.1650.63,
allows remote attackers to cause a denial of service (out-of-bounds
write) or possibly have unspecified other impact via JavaScript code
that sets the value of an array element with a crafted index.
Quoting CVE-2013-6640:
The DehoistArrayIndex function in hydrogen-dehoist.cc in Google V8
before 3.22.24.7, as used in Google Chrome before 31.0.1650.63,
allows remote attackers to cause a denial of service (out-of-bounds
read) via JavaScript code that sets a variable to the value of an
array element with a crafted index.
Like 6b92a7, this is unlikely to affect node.js because it only runs
local, trusted code. However, if there exists some module somewhere
that populates an array index with remotely provided data this could
very well be used to crash a remote server running node. Defense in
depth and all.
This is a backport of upstream commit r17801. Original commit log:
Limit size of dehoistable array indices
LOG=Y
BUG=chromium:319835,chromium:319860
R=dslomov@chromium.org
Review URL: https://codereview.chromium.org/74113002
`timezone` variable contains the difference, in seconds, between UTC and
local standard time (see `man 3 localtime` on Solaris).
Call to `tzset` is required to apply contents of `TZ` variable to
`timezone` variable.
BUG=v8:2064
Review URL: https://chromiumcodereview.appspot.com/10967066
Patch from Maciej Małecki <me@mmalecki.com>.
This is a back-port of upstream commit r12802 and a forward port of
commit 9fa953d from the v0.8 branch. V8 3.22 in the master branch
contains the patch so no further forward-porting is necessary.
The security fix from commit 6b92a713 also back-ported the test case.
Said test case relies on API that is only available in newer versions
of V8 and, as a result, broke the `make native` and `make <arch.mode>`
builds. This commit reverts that part of the back-port. Fixes the
following build error:
../test/cctest/test-api.cc: In function ‘void TestRegress260106()’:
../test/cctest/test-api.cc:17712:34: error: ‘class v8::Context’ has
no member named ‘GetIsolate’
Quoting the CVE:
Google V8, as used in Google Chrome before 28.0.1500.95, allows
remote attackers to cause a denial of service or possibly have
unspecified other impact via vectors that leverage "type confusion."
Likely has zero impact on node.js because it only runs local, trusted
code but let's apply it anyway.
This is a back-port of upstream commit r15665. Original commit log:
Use internal array as API function cache.
R=yangguo@chromium.org
BUG=chromium:260106
TEST=cctest/test-api/Regress260106
Review URL: https://codereview.chromium.org/19159003Fixes#5973.
Clang branch release_33 would optimize out a != NULL check because of
some undefined behavior. This is a floating patch as a backport of that
fix.
Committed: http://code.google.com/p/v8/source/detail?r=13570
Increase the number of bits by 1 by making Flags unsigned.
BUG=chromium:211741
Review URL: https://chromiumcodereview.appspot.com/12886008
This is a back-port of commits 13964 and 13988 addressing CVE-2013-2632.
Reapply floating patches. Special mention: also reapplies 017009f but
with the extra change of removing DescriptorArray::kTransitionsIndex
from the postmortem metadata generator because said field no longer
exists in V8 3.14.
Remove compiler switches from $(TOPLEVEL)/deps/v8/build/common.gypi,
we set them globally in $(TOPLEVEL)/common.gypi.
Commit 7b4d95a introduced the switches again, resulting in V8 getting
built without any optimizations.
This commit is essentially a rehash of commit 4b8629d.
Remove compiler switches from $(TOPLEVEL)/deps/v8/build/common.gypi,
we set them globally in $(TOPLEVEL)/common.gypi.
Commit 7b4d95a introduced the switches again, resulting in V8 getting
built without any optimizations.
This commit is essentially a rehash of commit 4b8629d.
Remove compiler switches from $(TOPLEVEL)/deps/v8/build/common.gypi,
we set them globally in $(TOPLEVEL)/common.gypi.
Commit 7b4d95a introduced the switches again, resulting in V8 getting
built without any optimizations.
This commit is essentially a rehash of commit 4b8629d.
* fix gyp build
* don't require libexecinfo, it's not there
* libpthread doesn't implement sem_timedwait(), fall back to sem_wait()
Upstreamed in https://codereview.chromium.org/11421013/
Timothy J Fontaine
Fedor Indutny
Felix Geisendörfer
Ben Noordhuis
Ben Noordhuis
Fedor Indutny
svenpanne@chromium.org
jkummerow@chromium.org
yangguo@chromium.org
mstarzinger@chromium.org
Andrei Sedoi
Trevor Norris
verwaest@chromium.org
isaacs
Bryan Cantrill