Garbage Collection Crash

[sehz]

• Version: v6.4.0:
• Platform: Mac 15.6.0 Darwin Kernel Version 15.6.0::
• ** OS X Version 10.11.6 (15G31)**:

Node crashed with following stack trace:

#
# Fatal error in ../deps/v8/src/execution.cc, line 64
# Check failed: AllowJavascriptExecution::IsAllowed(isolate).
#

==== C stack trace ===============================

 1: V8_Fatal
 2: v8::internal::(anonymous namespace)::Invoke(v8::internal::Isolate*, bool, v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::Object>, int, v8::internal::Handle<v8::internal::Object>*, v8::internal::Handle<v8::internal::Object>)
 3: v8::internal::Execution::Call(v8::internal::Isolate*, v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::Object>, int, v8::internal::Handle<v8::internal::Object>*)
 4: v8::Function::Call(v8::Local<v8::Context>, v8::Local<v8::Value>, int, v8::Local<v8::Value>*)
 5: node::TLSWrap::~TLSWrap()
 6: node::TLSWrap::~TLSWrap()
 7: v8::internal::GlobalHandles::DispatchPendingPhantomCallbacks(bool)
 8: v8::internal::GlobalHandles::PostGarbageCollectionProcessing(v8::internal::GarbageCollector, v8::GCCallbackFlags)
 9: v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags)
10: v8::internal::Heap::CollectGarbage(v8::internal::GarbageCollector, char const*, char const*, v8::GCCallbackFlags)
11: v8::internal::Factory::NewCodeRaw(int, bool)
12: v8::internal::Factory::NewCode(v8::internal::CodeDesc const&, unsigned int, v8::internal::Handle<v8::internal::Object>, bool, bool, int, bool)
13: v8::internal::CodeGenerator::MakeCodeEpilogue(v8::internal::MacroAssembler*, v8::internal::CompilationInfo*)
14: v8::internal::LChunk::Codegen()
15: v8::internal::OptimizedCompileJob::GenerateCode()
16: v8::internal::Compiler::GetConcurrentlyOptimizedCode(v8::internal::OptimizedCompileJob*)
17: v8::internal::OptimizingCompileDispatcher::InstallOptimizedFunctions()
18: v8::internal::StackGuard::HandleInterrupts()
19: v8::internal::Runtime_StackGuard(int, v8::internal::Object**, v8::internal::Isolate*)
20: 0xe170e00961b
21: 0xe170e6cb2e5

Process finished with exit code 132 (interrupted by signal 4: SIGILL)

[mscdex]

/cc @indutny

[addaleax]

@sehyoc Thanks for reporting this! Is there any chance you can offer more information? Is the problem reproducible? Do you have something like a test script that can demonstrate the issue?

[mscdex]

Also: do you know if there is a node version where the same code was working, or is this the first version of node you tried?

[indutny]

I have no other suspects but the AsyncWrap class. @trevnorris looks like calling JS functions is no longer allowed from the ~AsyncWrap, is it something that we should look into?

[bnoordhuis]

I agree with Fedor that the call into the VM from the AsyncWrap destructor is responsible.

@sehyoc Something in your project (either your own code or a third-party module) is calling process.binding('async_wrap').setupHooks(). Try disabling that for now as a workaround.

[sehz]

This problem is reproducible but not everytime. Crashes happen 1 of 5 times during startup. Before I was running v6.3.1 which also crashed but much less frequency.

We are using babel with async plug-in. Since we are heavily relying on 'async' keyword, there is no way to turn this off.

[addaleax]

@sehyoc This is not about the async keyword, async_wrap is something very different. Are you sure nothing in your project is touching process.binding('async_wrap')? grep -R async_wrap . should be a reasonable way to check for that.

[sehz]

Yes, I found who was using async_wrap. It was async-hook package:

node_modules/async-hook/async-hook.js:const asyncWrap = process.binding('async_wrap'); Binary file node_modules/electron-prebuilt/dist/Electron.app/Contents/Frameworks/Electron Framework.framework/Libraries/libnode.dylib matches Binary file node_modules/electron-prebuilt/dist/Electron.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Libraries/libnode.dylib matches Binary file node_modules/electron-prebuilt/dist/Electron.app/Contents/Frameworks/Electron Framework.framework/Versions/Current/Libraries/libnode.dylib matches

And furthermore, async-hook was used by:
node_modules/trace/package.json: "async-hook": "^1.0.0", node_modules/trace/trace.js:const asyncHook = require('async-hook');

I was using to get long stack trace. Current version of trace still using async-hook. I removed the package