Don't use argument as callback if it's not a valid callback function.
Throw a valid exception instead explaining the issue. Adds to #7070
("DNS — Throw meaningful error(s)").
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.
Conditional globals like 'gc' should only be recognized when --expose_gc
is set. The global.gc feature check works only when done eagerly, else
it lets through a leaked variable called 'gc'.
Before, `new String('foo')` would be inspected as `"{}"` which
is simply not very helpful. Now, a more meaningful
`"[String: 'foo']"` result will be returned from `util.inspect()`.
Boxed String, Boolean, and Number types are all supported.
Closes#7047
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>
Add a new 'tracing' module with a v8 property that lets the user
register listeners for gc events. The listeners are invoked after
every garbage collection cycle with 'before' and 'after' statistics.
Useful for monitoring tools that want to keep track of memory usage.
Create a new HandleScope before looking up the object context with
v8::Object::CreationContext(), else we leak the Local<Context> into
the current HandleScope.
That's relatively harmless unless the HandleScope is long-lived and
MakeCallback() is called a lot. In a scenario like that, we may end
up leaking a lot of memory.
What is unfortunate about this change is that we're trying hard to
eradicate the node_isolate global. Longer term, we will probably have
to change the MakeCallback() prototype to one that requires an explicit
v8::Isolate* argument.
Make it possible to invoke MakeCallback() on a v8::Value but only for
the variant that takes a v8::Function as the thing to call.
The const char* and v8::String variants still require a v8::Object
because the function to call is looked up as a property on the receiver,
but that only works when the receiver is an object, not a primitive.
If the call to writeBuffer completes asynchronously, we need to have
an oncomplete callback on the request object no matter what. The
writeQueueSize seems irrelvant to that regard.
Note that on Windows writeBuffer always completes asynchronously.
See related commit 9836a4eeda
Update the list of root certificates in src/node_root_certs.h with
tools/mk-ca-bundle.pl and update src/node_crypto.cc to make use of
the new format.
Fixes#6013.
`tls_wrap.cc` was crashing in an `Unwrap` call, when non
`SecureContext` object was passed to it. Check that the passed object
is a `SecureContext` instance before unwrapping it.
fix#7008
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 test is no longer valid for the original scenario.
It now fails intermittently because of two other issues:
1. Since the client is only processing one readable event, the
client request is not enough to keep the process alive and the
process can exit before the desired events have been raised.
2. Reading just 1 byte is not enough to guarantee that the parser
will eventually consume all the data and raise the desired
parse error. I tried postponing the server.close() to address
the issue at [1], but then the test just hangs sometimes.
Even if stdio streams are opened as file streams, we should not ever try
to close them. This could be accomplished by passing `autoClose: false`
in options on their creation.
Even if stdio streams are opened as file streams, we should not ever try
to close them. This could be accomplished by passing `autoClose: false`
in options on their creation.
Timothy J Fontaine
isaacs
Brian White
Fedor Indutny
Kenan Sulayman
Austin Moran
Ben Noordhuis
Nathan Rajlich
iamdoron
Trevor Norris
Alexis Campailla
Benjamin Waters
Yuriy Nemtsov
Oguz Bastemur
Maxime Quandalle
Nikolai Vavilov
Wyatt Preul
Thom Seddon