Commit 8aed9d66 ("src: cleanup `Isolate::GetCurrent()`") breaks building
add-ons because of the following:
In file included from ../node_modules/nan/nan.h:27:0,
from ../src/binding.cc:18:
/home/bnoordhuis/src/v1.x/src/node_object_wrap.h: In member function
'v8::Local<v8::Object> node::ObjectWrap::handle()':
/home/bnoordhuis/src/v1.x/src/node_object_wrap.h:39:46: error: base
operand of '->' has non-pointer type 'v8::Persistent<v8::Object>'
return v8::Local<v8::Object>::New(handle_->GetIsolate(),
persistent());
Mea culpa, I was one of the reviewers.
PR-URL: https://github.com/iojs/io.js/pull/868
Reviewed-By: Vladimir Kurchatkin <vladimir.kurchatkin@gmail.com>
The copyright and license notice is already in the LICENSE file. There
is no justifiable reason to also require that it be included in every
file, since the individual files are not individually distributed except
as part of the entire package.
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.
We need to keep ObjectWrap around for module authors (we think), but
v8 3.21 broke node_object_wrap.h with respect to MSVC. Coincidentally,
we no longer use ObjectWrap at all in core, and native modules might
as well use their own entirely internal implementation if they need it.
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 is a big commit that touches just about every file in the src/
directory. The V8 API has changed in significant ways. The most
important changes are:
* Binding functions take a const v8::FunctionCallbackInfo<T>& argument
rather than a const v8::Arguments& argument.
* Binding functions return void rather than v8::Handle<v8::Value>. The
return value is returned with the args.GetReturnValue().Set() family
of functions.
* v8::Persistent<T> no longer derives from v8::Handle<T> and no longer
allows you to directly dereference the object that the persistent
handle points to. This means that the common pattern of caching
oft-used JS values in a persistent handle no longer quite works,
you first need to reconstruct a v8::Local<T> from the persistent
handle with the Local<T>::New(isolate, persistent) factory method.
A handful of (internal) convenience classes and functions have been
added to make dealing with the new API a little easier.
The most visible one is node::Cached<T>, which wraps a v8::Persistent<T>
with some template sugar. It can hold arbitrary types but so far it's
exclusively used for v8::Strings (which was by far the most commonly
cached handle type.)
Commit 0bba5902 accidentally (or maybe erroneously) added node_isolate
to src/node.h and src/node_object_wrap.h.
Undo that, said variable is not for public consumption. Add-on authors
should use v8::Isolate::GetCurrent() instead.
I missed that while reviewing. Mea culpa.
Fixes#5639.
Call SetPointerInInternalField(0, NULL) rather than
SetInternalField(0, Undefined()).
Fixes the following spurious NULL pointer dereference in debug builds:
#0 0x03ad2821 in v8::internal::FixedArrayBase::length ()
#1 0x03ad1dfc in v8::internal::FixedArray::get ()
#2 0x03ae05dd in v8::internal::Context::global_object ()
#3 0x03b6b87d in v8::internal::Context::builtins ()
#4 0x03ae1871 in v8::internal::Isolate::js_builtins_object ()
#5 0x03ab4fab in v8::CallV8HeapFunction ()
#6 0x03ab4d4a in v8::Value::Equals ()
#7 0x03b4f38b in CheckEqualsHelper ()
#8 0x03ac0f4b in v8::Object::SetInternalField ()
#9 0x06a99ddd in node::ObjectWrap::~ObjectWrap ()
#10 0x06a8b051 in node::Buffer::~Buffer ()
#11 0x06a8afbb in node::Buffer::~Buffer ()
#12 0x06a8af5e in node::Buffer::~Buffer ()
#13 0x06a9e569 in node::ObjectWrap::WeakCallback ()
All compile time warnings about using deprecated APIs have been
suppressed by updating node's API. Though there are still many function
calls that can accept Isolate, and still need to be updated.
node_isolate had to be added as an extern variable in node.h and
node_object_wrap.h
Also a couple small fixes for Error handling.
Before v8 3.16.6 the error stack message was lazily written when it was
needed, which allowed you to change the message after instantiation.
Then the stack would be written with the new message the first time it
was accessed. Though that has changed. Now it creates the stack message
on instantiation. So setting a different message afterwards won't be
displayed.
This is not a complete fix for the problem. Getting error without any
message isn't very useful.
These explicit instantiations were added to make MSVC happy. It turns
out that some older versions of gcc and llvm now complain about duplicate
symbols, so we instantiate these templates only when MSVC is used.
These explicit instantiations were added to make MSVC happy. It turns
out that some older versions of gcc and llvm now complain about duplicate
symbols, so we instantiate these templates only when MSVC is used.
However it's not working very well: Hitting a 'hello world' server with many
requests (ab -t 60 -c 10) will cause it to crash with the following error.
Obtained 3 stack frames.
./node(_Z11print_tracev+0x1c) [0x80d1b3c]
./node(_ZN4node6Parser7ExecuteERKN2v89ArgumentsE+0x69) [0x80d3759]
./node [0x811f44b]
TypeError: Already parsing a buffer
at Socket.<anonymous> (/home/ryan/projects/node/lib/http2.js:393:20)
at IOWatcher.callback (/home/ryan/projects/node/lib/net.js:81:12)
at node.js:985:9
at node.js:989:1
Had to add some waf hackery to override V8's architecture choice. They
probably have a reason for defaulting still to IA32, but all tests are
passing for me, and it makes it easier on users-and I think chrome is using
x64 builds too. So let's go for it!
James M Snell
Ali Ijaz Sheikh
Michaël Zasso
Ben Noordhuis
Vladimir Kurchatkin
isaacs
Fedor Indutny
Scott Blomquist
Trevor Norris
Bert Belder
Bert Belder
Ryan Dahl