Don't call DecodeWrite() with a Buffer as its argument because it in
turn calls StringBytes::Write() and that method expects a Local<String>.
"Why then does that function take a Local<Value>?" I hear you ask.
Good question but I don't have the answer. I added a CHECK for good
measure and what do you know, all of a sudden a large number of crypto
tests started failing.
Calling DecodeWrite(BINARY) on a buffer is nonsensical anyway: if you
want the contents of the buffer, just copy out the data, there is no
need to decode it - and that's exactly what this commit does.
Fixes a great many instances of the following run-time error in debug
builds:
FATAL ERROR: v8::String::Cast() Could not convert to string
Fix a regression that was introduced in commit ce04c726 after the
upgrade to V8 3.24.
The new weak persistent handle API no longer gives you the original
persistent but still requires that you clear it inside your weak
callback.
Rearrange the code in src/smalloc.cc to keep track of the persistent
handle with the least amount of pain and try hard to share as much
code as possible between the 'just free it' and 'invoke my callback'
versions of the smalloc API.
Fixes#7309.
Conform to the Google styleguide more and make cpplint happy, add more
CHECK macros.
Preemptively addresses cpplint's readability/check warnings ("Consider
using CHECK_GT instead of CHECK(a > b)".)
Make calls to v8::Isolate::AdjustAmountOfExternalAllocatedMemory() take
special care when negating 32 bits unsigned types like size_t.
Before this commit, values were negated before they got promoted to
64 bits, meaning that on 32 bits architectures, a value like 42 got
cast to 4294967254 instead of -42.
That in turn made the garbage collector start scavenging like crazy
because it thought the system was out of memory.
That's bad enough but calls to AdjustAmountOfExternalAllocatedMemory()
were made from weak callbacks, i.e. at a time when the garbage collector
was already busy. It triggered asserts in debug builds and caused
random crashes and memory corruption in release builds.
The behavior in release builds is arguably a V8 bug and should perhaps
be reported upstream.
Partially fixes#7309 but requires further bug fixes to src/smalloc.cc
that I'll address in a follow-up commit.
The variable isn't actually used uninitialized but g++ 4.8 doesn't know
that. Set it to NULL to silence the following compiler warning:
../src/string_bytes.cc:247:29: warning: 'data' may be used
uninitialized in this function [-Wmaybe-uninitialized]
unsigned a = hex2bin(src[i * 2 + 0]);
^
../src/string_bytes.cc:299:15: note: 'data' was declared here
const char* data;
^
V8 was upgraded from 3.22 to 3.24 in commit 1c7bf24. Upgrade source
files in test/addons/ and automatically generated tests from
doc/api/addons.markdown to the new V8 API.
This coincidentally fixes a bug in src/node_object_wrap.h where it was
still using the old V8 weak persistent handle interface, which is gone
in 3.24.
Previously if you wanted to be notified of pending handles for pipes
you needed to use uv_read2_start, however in v0.11.22 you can query for
pending handles independently.
It's currently not really possible to compile native add-ons with
-fvisibility=hidden because that also hides the struct containing
the module definition.
The NODE_MODULE() and NODE_MODULE_DECL() macros are structured in
a way that makes it impossible to add a visibility attribute manually
so there is no escape hatch there.
That's why this commit adds an explicit visibility attribute to
the module definition. It doesn't help with node.js releases that
are already out there but at least it improves the situation going
forward.
Previously if you cached process.nextTick and then require('domain')
subsequent nextTick() calls would not be caught because enqueued
functions were taking the wrong path. This keeps nextTick to a single
function reference and changes the implementation details after domain
has been required.
When `setImmediate(cb)` is called in `beforeExit` event handler the
consequent `uv_run(..., UV_RUN_NOWAIT)` may return `0`, even if there
was some active handles at start.
Fixes simple/test-beforeexit-event.js.
Unlike the 'exit' event, this event allows the user to schedule more
work and thereby postpone the exit. That also means that the
'beforeExit' event may be emitted many times, see the attached test
case for an example.
Refs #6305.
libuv gyp builds now require you to define the library disposition
(static or shared).
Also, libuv now supports vectored IO for file system reads and writes,
update to those function signatures
Expose `setBlocking` on Pipe's and if a pipe is being created for stdio
on windows then make the pipes blocking.
This fixes test-stream2-stderr-sync.js on Windows.
Fixes#3584
NodeBIO::Gets was reading off the end of a buffer if it
didn't find a "\n" before the EOF. This behavior
was causing X509 certificates passed to `https.Agent`
via the "ca" option to be silently discarded. It also
was causing improper parsing of certs and keys
passed to https.Agent, but those problems were worked
around in cdde9a3.
Backed out workaround in `lib/crypto.js` from ccde9a3,
which now isn't needed. But keep the test introduced
in that commit, which tests properly for this
bug.
This bug was first introduced in a58f93f
Gist containing test code, bisection log, and notes:
https://gist.github.com/maxtaco/9211605
The linker was optimizing the static variables that were supposed
to trigger module initialization.
I am making them non-static, and dllexport so that they don't get
optimized away.
Fixes#7116
Make vm.runInContext() and vm.runInNewContext() stop copying the Proxy
object from the parent context into the new context when --harmony or
--harmony_proxies is in effect because it overwrites the new context's
native Proxy object.
This commit also adds a regression test for Harmony symbols. They work
okay in the current implementation and the test should ensure it stays
that way.
Try embedding the ` ... ^` lines inside the `SyntaxError` (or any other
native error) object before giving up and printing them to the stderr.
fix#6920fix#1310
The AsyncListener API has been moved into the "tracing" module in order
to keep the process object free from unnecessary clutter.
Signed-off-by: Timothy J Fontaine <tjfontaine@gmail.com>
Now the second field in asyncFlags will tell if the provider is
currently being watched, or listened for.
Signed-off-by: Timothy J Fontaine <tjfontaine@gmail.com>
These will be used to allow users to filter for which types of calls
they wish their callbacks to run.
Signed-off-by: Timothy J Fontaine <tjfontaine@gmail.com>
"flags" could mean one of many things, and multiple flag types could be
checked. So make the field more explicit on what type of flags are being
stored.
Signed-off-by: Timothy J Fontaine <tjfontaine@gmail.com>
Ben Noordhuis
Fedor Indutny
Timothy J Fontaine
Saúl Ibarra Corretgé
Brian White
Alexis Campailla
Maxwell Krohn
Xidorn Quan
Bert Belder
Austin Moran
Trevor Norris