Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FATAL ERROR: v8::HandleScope::CreateHandle() Cannot create a handle without a HandleScope #440

Closed
andrewrk opened this issue Sep 1, 2015 · 11 comments

Comments

@andrewrk
Copy link

andrewrk commented Sep 1, 2015

When testing my native addon with iojs 3 I get

FATAL ERROR: v8::HandleScope::CreateHandle() Cannot create a handle without a HandleScope

I'm following the pattern in test/cpp/objectwraphandle.cpp. The line it crashes on is this one:

v8::Local<v8::Function> cons = Nan::New(constructor);

I tried to run the test to see if it would pass, but #439 happened.

@kkoopa
Copy link
Collaborator

kkoopa commented Sep 1, 2015

You have to actually declare your handle scopes. It should be Nan::HandleScope scope;, since Nan::HandleScope(); immediately destroys the created scope.

@kkoopa kkoopa closed this as completed Sep 1, 2015
@andrewrk
Copy link
Author

andrewrk commented Sep 1, 2015

Here's my code:

Local<Value> GNFile::NewInstance(GrooveFile *file) {
    Nan::EscapableHandleScope scope;

    Local<Function> cons = Nan::New(constructor);
    Local<Object> instance = cons->NewInstance();

    GNFile *gn_file = node::ObjectWrap::Unwrap<GNFile>(instance);
    gn_file->file = file;

    return scope.Escape(instance);
}

Backtrace of the abort:

#1  0x00007ffff5f177ea in abort ()
   from /nix/store/qlxp7vb63fp8kx5vk9a0y3rj8svbvl27-glibc-2.21/lib/libc.so.6
#2  0x0000000000b44bf3 in node::OnFatalError(char const*, char const*) ()
#3  0x000000000064b095 in v8::Utils::ReportApiFailure(char const*, char const*) ()
#4  0x00000000007f7cff in v8::internal::HandleScope::Extend(v8::internal::Isolate*) ()
#5  0x000000000064be28 in v8::EscapableHandleScope::EscapableHandleScope(v8::Isolate*) ()
#6  0x00007ffff3aabfc7 in Nan::EscapableHandleScope::EscapableHandleScope (
    this=0x7fffffff8e90) at ../node_modules/nan/nan.h:352
#7  0x00007ffff3aaa305 in GNFile::NewInstance (file=0x7fffd40008c0) at ../src/file.cc:46

file.cc:46 is Nan::EscapableHandleScope scope;

@andrewrk
Copy link
Author

andrewrk commented Sep 1, 2015

you nailed it though, I replaced all the Nan::HandleScope() in my codebase with Nan::HandleScope scope and that fixed the problem. thanks!

@jain009deep
Copy link

Any solution to above problem? I am getting same error while using "java" node module with node v 4.x.x. It was ok til node v 0.10.36.

@kkoopa
Copy link
Collaborator

kkoopa commented Oct 27, 2015

Declare HandleScopes where necessary.

@eelcocramer
Copy link

I have a similar issue where this error occurs in the line where I declare an EscapableHandleScope. When I declare a HandleScope before that line the error doesn't occur.

It doesn't make sense to have to declare a HandleScope before an EscapableHandleScope does it?

Code can be found here

@kkoopa
Copy link
Collaborator

kkoopa commented Oct 28, 2015

No, that does not make sense. Let's see now. There's a mention of some issue workaround, that should not happen or be necessary. It seems to be a remnant of something old, there is no reason it would return a bad handle in this day and age. Remove that and the EscapableHandleScope and you should be all set. Also, the scopes in the NAN_METHODs are unnecessary and can be removed.

@kkoopa
Copy link
Collaborator

kkoopa commented Oct 28, 2015

Actually, that code has been wrong forever. Already this commit was an incorrect fix: eelcocramer/node-bluetooth-serial-port@7eeb85f

@eelcocramer
Copy link

Thanks a lot for the feedback!

@kkoopa
Copy link
Collaborator

kkoopa commented Oct 28, 2015

I think I saw similar weirdness (besides that strange 'fix') pop up in other places while skimming through the code base, so better do a thorough inspection of the code for all platforms.

Every function not directly exposed to V8 which creates handles (or does anything with V8 to be sure) should have a HandleScope or EscapableHandleScope. Save for doing weird stuff with nested scopes in scopes, EscapableHandleScope should only be used when returning handles from the function. If it returns void or a non-V8 type, use HandleScope. Having scopes is of utmost importance in libuv callbacks, without them you get the titular fatal error.

@eelcocramer
Copy link

👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants