Before this commit, the SIGUSR1 signal handler wasn't installed until
late in the bootstrapping process and we were prone to miss signals
sent by other processes.
This commit installs an early-boot signal handler that merely records
the fact that we received a signal. Once the debugger infrastructure
is in place, the signal is re-raised, kickstarting the debugger.
Among other things, this means that simple/test-debugger-client is
now _much_ less likely to fail.
Commit 30e5366b ("core: Use a uv_signal for debug listener") changed
SIGUSR1 handling from a signal handler to libuv's uv_signal_*()
functionality to fix a race condition (and possible hang) in the
signal handler.
While a good change in itself, it made it impossible to interrupt
long running scripts. When a script is stuck in a busy loop, control
never returns to the event loop, which in turn means the signal
callback - and therefore the debugger - is never invoked.
This commit changes SIGUSR1 handling back to a normal signal handler
but one that treads _very_ carefully.
Because it's possible for the data within a Buffer instance to be
altered after instantiation, or in case a user attempts to do something
like the following:
Buffer.prototype.fill.call({}, 10, 0, 10);
It doesn't result in a segfault.
This change makes several improvements to the ustack helper and MDB
support:
- ustack helper and MDB: add support for two-byte strings
(necessary to print many filenames in stacktraces in 0.10 and later).
- ustack helper: fix position numbers, which were off by a factor of two
- ustack helper: fix frames with undefined Scripts (e.g., "RegExp")
- ustack helper: add stub frames
- MDB: add support for sliced strings
- MDB: sync up with changes from the illumos version of the module
Fixes#6309Closes#6318
Mea culpa, I didn't properly resolve a merge conflict in the last two
commits. The resulting segmentation fault only happened on Linux and
only sometimes.
Fixes#6306.
The previous commit changes the profiler idle notifier so that it only
gets started when a --prof or --prof_lazy argument is specified on the
command line.
This commit adds two internal methods to the process object that allows
one to start and stop the idle notifier programmatically.
The previous commit adds a notifier that tells the V8 profiler when
node.js is idle, i.e. when it's about to start sleeping in the
platform's equivalent of epoll_wait().
This commit adds a heuristic that only starts the notifier when the
V8 profiler is started from the command line.
Inform V8's CPU profiler when we're idle. The profiler is
sampling-based but not all samples are created equal; mark the wall
clock time spent in epoll_wait() and friends so profiling tools can
filter it out. The samples still end up in v8.log but with state=IDLE
rather than state=EXTERNAL.
Drop the ObjectWrap dependency in favor of an internal WeakObject class.
Let's us stop worrying about API and ABI compatibility when making
changes to the way node.js deals with weakly persistent handles
internally.
The default entropy source is /dev/urandom on UNIX platforms, which is
okay but we can do better by seeding it from OpenSSL's entropy pool.
On Windows we can certainly do better; on that platform, V8 seeds the
random number generator using only the current system time.
Fixes#6250.
The test case from the previous commit exposed a regression in the way
that c-ares errors are reported to JS land. Said regression was
introduced in commit 756b622 ("src: add multi-context support").
Fixes the following test failure:
$ out/Release/node test/simple/test-dns-regress-6244
util.js:675
var errname = uv.errname(err);
^
Error: err >= 0
at Object.exports._errnoException (util.js:675:20)
at errnoException (dns.js:43:15)
at Object.onresolve [as oncomplete] (dns.js:145:19)
lib/dns.js erroneously assumed that the error code was a libuv error
code when it's really a c-ares status code. Libuv handles getaddrinfo()
style lookups (which is by far the most common type of lookup), that's
why this bug wasn't discovered earlier.
Don't forget to initialize the c-ares task tree head when creating a
new Environment. Oversight from the multi-context work that landed
in commit 756b622.
Fixes#6244.
Apparently, context->Global() won't be destroyed if the context itself
isn't marked as weak and independent.
Also, the weakness flag should be cleared once the weak callback is
executed, otherwise we'll get crashes in Debug builds.
fix#6115 and #6201
Functions created using: `vm.runInNewContext('(function() { })')` will
reference only `proxy_global_` object and not `sandbox_`. Thus in case,
where there're no references to sandbox (such as in example above),
`ContextifyContext` will be destroyed and use-after-free might happen.
Since it is Unix tradition to use exit code 1 for general-purpose script
bail-out, and the way of doing that in Node is to throw an exception and
not catch it, it makes the most sense to exit with 1 when an exception
goes uncaught.
Move the `Invalid Argument` exit to 9, so that it's something specific,
and clear that it's a node internal error.
Also, document the exit codes that we use.
Fix pointer unwrapping when T is a class with more than one base class.
Before this commit, the wrapped void* pointer was cast directly to T*
without going through ObjectWrap* first, possibly leading to a class
instance pointer that points to the wrong vtable.
This change required some cleanup in various files; some classes
used private rather than public inheritance, others didn't derive
from ObjectWrap at all...
Fixes#6188.
This commit makes it possible to use multiple V8 execution contexts
within a single event loop. Put another way, handle and request wrap
objects now "remember" the context they belong to and switch back to
that context when the time comes to call into JS land.
This could have been done in a quick and hacky way by calling
v8::Object::GetCreationContext() on the wrap object right before
making a callback but that leaves a fairly wide margin for bugs.
Instead, we make the context explicit through a new Environment class
that encapsulates everything (or almost everything) that belongs to
the context. Variables that used to be a static or a global are now
members of the aforementioned class. An additional benefit is that
this approach should make it relatively straightforward to add full
isolate support in due course.
There is no JavaScript API yet but that will be added in the near
future.
This work was graciously sponsored by GitHub, Inc.
From commit 756ae2c all the WRAP/UNWRAP were moved to a single location
for ease of use. In a single location NO_ABORT should have been used but
wasn't. This caused HandleWrap::Close to abort. Below is the applicable
code change as demonstration there was no abort specified when
unwrapping the object.
void HandleWrap::Close(const FunctionCallbackInfo<Value>& args) {
HandleScope scope(node_isolate);
- HandleWrap *wrap = static_cast<HandleWrap*>(
- args.This()->GetAlignedPointerFromInternalField(0));
+ HandleWrap* wrap;
+ UNWRAP(args.This(), HandleWrap, wrap);
Also included a test that will reproduce the abort.
Stop gcc from getting confused, explicitly cast the return value from
getuid() and getgid() to uint32_t. Fixes the following build error:
../src/node.cc: In function 'void node::GetUid(const
v8::FunctionCallbackInfo<v8::Value>&)':
../src/node.cc:1552:37: error: call of overloaded 'Set(uid_t)' is
ambiguous
../src/node.cc:1552:37: note: candidates are:
../deps/v8/include/v8.h:5939:6: note: void
v8::ReturnValue<T>::Set(bool) [with T = v8::Value]
../deps/v8/include/v8.h:5909:6: note: void
v8::ReturnValue<T>::Set(double) [with T = v8::Value]
../deps/v8/include/v8.h:5915:6: note: void
v8::ReturnValue<T>::Set(int32_t) [with T = v8::Value, int32_t = int]
../deps/v8/include/v8.h:5926:6: note: void
v8::ReturnValue<T>::Set(uint32_t) [with T = v8::Value, uint32_t =
unsigned int]
Fixes#6182.
This commit changes src/tcp_wrap.cc and src/udp_wrap.cc just enough to
get by (i.e. to compile and function correctly.)
The new libuv API allows for more cleanup and deduplication but I'm
saving that for another day.
If the string is external then the length can be quickly retrieved. This
is especially faster for large strings that are being treated as UTF8.
Also, if the string is external then there's no need for a full
String::WriteUtf8 operation. A simple memcpy will do.
Timothy J Fontaine
Fedor Indutny
Ben Noordhuis
Jason Gerfen
isaacs
Trevor Norris
Dave Pacheco