Repository navigation
--cpu-prof crashes in debug builds when code cache is enabled #27307
Description
Activity
Another stack trace without optimized debug
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT) * frame #0: 0x00000001005078ed node`v8::internal::Map::instance_type(this=0x00007ffeefbf9990) const at map-inl.h:292 frame #1: 0x00000001005103da node`v8::internal::HeapObject::IsString(this=0x00007ffeefbf9a00) const at instance-type-inl.h:70 frame #2: 0x000000010165cd48 node`v8::internal::ProfilerListener::InferScriptName(this=0x000000010702b120, name=Name @ 0x00007ffeefbf9a00, info=SharedFunctionInfo @ 0x00007ffeefbf99f8) at profiler-listener.cc:265 frame #3: 0x000000010165fa50 node`v8::internal::ProfilerListener::CodeCreateEvent(this=0x000000010702b120, tag=SCRIPT_TAG, abstract_code=AbstractCode @ 0x00007ffeefbf9ed0, shared=SharedFunctionInfo @ 0x00007ffeefbf9ec8, script_name=Name @ 0x00007ffeefbf9ec0, line=1, column=1) at profiler-listener.cc:172 frame #4: 0x00000001007c874d node`v8::internal::CodeEventDispatcher::CodeCreateEvent(this=0x0000000107002340, tag=SCRIPT_TAG, code=AbstractCode @ 0x00007ffeefbfb110, shared=SharedFunctionInfo @ 0x00007ffeefbfb108, source=Name @ 0x00007ffeefbfb100, line=1, column=1) at code-events.h:142 frame #5: 0x00000001018005cb node`v8::internal::CodeSerializer::Deserialize(isolate=0x0000000108000000, cached_data=0x0000000105c05110, source=Handle<v8::internal::String> @ 0x00007ffeefbfb490, origin_options=(flags_ = 1)) at code-serializer.cc:276 frame #6: 0x00000001007c55e9 node`v8::internal::Compiler::GetWrappedFunction(source=Handle<v8::internal::String> @ 0x00007ffeefbfb840, arguments=Handle<v8::internal::FixedArray> @ 0x00007ffeefbfb838, context=Handle<v8::internal::Context> @ 0x00007ffeefbfb830, script_details=0x00007ffeefbfb948, origin_options=(flags_ = 1), cached_data=0x0000000105c05110, compile_options=kConsumeCodeCache, no_cache_reason=kNoCacheNoReason) at compiler.cc:1936 frame #7: 0x000000010053f2b1 node`v8::ScriptCompiler::CompileFunctionInContext(v8_context=(val_ = 0x000000010880c920), source=0x00007ffeefbfbcf0, arguments_count=6, arguments=0x0000000105c02f70, context_extension_count=0, context_extensions=0x0000000000000000, options=kConsumeCodeCache, no_cache_reason=kNoCacheNoReason) at api.cc:2545 frame #8: 0x000000010022bd19 node`node::native_module::NativeModuleLoader::LookupAndCompile(this=0x000000010359d5b8, context=(val_ = 0x000000010880c920), id="path", parameters=0x00007ffeefbfc790 size=6, result=0x00007ffeefbfc914) at node_native_module.cc:217 frame #9: 0x000000010022ad0e node`node::native_module::NativeModuleLoader::CompileAsModule(this=0x000000010359d5b8, context=(val_ = 0x000000010880c920), id="path", result=0x00007ffeefbfc914) at node_native_module.cc:173 frame #10: 0x00000001002373ae node`node::native_module::NativeModuleEnv::CompileFunction(args=0x00007ffeefbfcda8) at node_native_module_env.cc:128 frame #11: 0x00000001006d95b4 node`v8::internal::FunctionCallbackArguments::Call(this=0x00007ffeefbfcf58, handler=CallHandlerInfo @ 0x00007ffeefbfce70) at api-arguments-inl.h:157 frame #12: 0x00000001006d729a node`v8::internal::MaybeHandle<v8::internal::Object> v8::internal::(anonymous namespace)::HandleApiCallHelper<false>(isolate=0x0000000108000000, function=Handle<v8::internal::HeapObject> @ 0x00007ffeefbfd0c0, new_target=Handle<v8::internal::HeapObject> @ 0x00007ffeefbfd0b8, fun_data=Handle<v8::internal::FunctionTemplateInfo> @ 0x00007ffeefbfd0b0, receiver=Handle<v8::internal::Object> @ 0x00007ffeefbfd0a8, args=BuiltinArguments @ 0x00007ffeefbfd0e0) at builtins-api.cc:109 frame #13: 0x00000001006d5310 node`v8::internal::Builtin_Impl_HandleApiCall(args=BuiltinArguments @ 0x00007ffeefbfd250, isolate=0x0000000108000000) at builtins-api.cc:139 frame #14: 0x00000001006d4da5 node`v8::internal::Builtin_HandleApiCall(args_length=6, args_object=0x00007ffeefbfd348, isolate=0x0000000108000000) at builtins-api.cc:127 frame #15: 0x00000001028d9ba9 node`Builtins_CEntry_Return1_DontSaveFPRegs_ArgvOnStack_NoBuiltinExit + 73 frame #16: 0x00000001025870f5 node`Builtins_InterpreterEntryTrampoline + 981 frame #17: 0x00000001025870f5 node`Builtins_InterpreterEntryTrampoline + 981 frame #18: 0x00000001025870f5 node`Builtins_InterpreterEntryTrampoline + 981 frame #19: 0x00000001025870f5 node`Builtins_InterpreterEntryTrampoline + 981 frame #20: 0x00000001025870f5 node`Builtins_InterpreterEntryTrampoline + 981 frame #21: 0x00000001025870f5 node`Builtins_InterpreterEntryTrampoline + 981 frame #22: 0x000000010257c7bd node`Builtins_JSEntryTrampoline + 93 frame #23: 0x000000010257c538 node`Builtins_JSEntry + 120 frame #24: 0x0000000100ef3f7c node`v8::internal::GeneratedCode<unsigned long, unsigned long, unsigned long, unsigned long, unsigned long, long, unsigned long**>::Call(this=0x00007ffeefbfdb08, args=4429185152, args=59452213953745, args=59453608359473, args=59452213953745, args=6, args=0x000000010702bd10) at simulator.h:138 frame #25: 0x0000000100ef1385 node`v8::internal::(anonymous namespace)::Invoke(isolate=0x0000000108000000, params=0x00007ffeefbfdda8)::InvokeParams const&) at execution.cc:274 frame #26: 0x0000000100ef095f node`v8::internal::Execution::Call(isolate=0x0000000108000000, callable=Handle<v8::internal::Object> @ 0x00007ffeefbfde10, receiver=Handle<v8::internal::Object> @ 0x00007ffeefbfde08, argc=6, argv=0x000000010702bd10) at execution.cc:366 frame #27: 0x0000000100557ccd node`v8::Function::Call(this=0x00000001080568c8, context=(val_ = 0x000000010880c920), recv=(val_ = 0x0000000108000058), argc=6, argv=0x000000010702bd10) at api.cc:4984 frame #28: 0x0000000100115096 node`node::ExecuteBootstrapper(env=0x0000000108809000, id="internal/bootstrap/node", parameters=0x00007ffeefbfe280 size=6, arguments=0x00007ffeefbfe258 size=6) at node.cc:204 frame #29: 0x00000001001164b4 node`node::RunBootstrapping(env=0x0000000108809000) at node.cc:332 frame #30: 0x000000010020d64e node`node::NodeMainInstance::CreateMainEnvironment(this=0x00007ffeefbff160, exit_code=0x00007ffeefbfee14) at node_main_instance.cc:155 frame #31: 0x000000010020c545 node`node::NodeMainInstance::Run(this=0x00007ffeefbff160) at node_main_instance.cc:47 frame #32: 0x000000010011e2ed node`node::Start(argc=3, argv=0x0000000107000000) at node.cc:863 frame #33: 0x000000010212d15e node`main(argc=3, argv=0x00007ffeefbff5d8) at node_main.cc:126 frame #34: 0x00007fff7890c015 libdyld.dylib`start + 1 frame #35: 0x00007fff7890c015 libdyld.dylib`start + 1- added a commit that references this issue
on Apr 19, 2019 https://gist.github.com/addaleax/139800e79fd687776f409edbaf35b981 fixes this for me, locally – @joyeecheung does that change look right to you? I can open a CL if you think so, but I haven’t done this kind of change in V8 before… like, whether this is enough or the handle itself should be passed as the argument instead of dereferencing it for the function calls, etc.
@addaleax I am not sure if this is sufficient either..please open a CL in the upstream, thanks!
Is this fixed on master now ?
$ out/Debug/node -p process.features { inspector: true, debug: true, uv: true, ipv6: true, tls_alpn: true, tls_sni: true, tls_ocsp: true, tls: true, cached_builtins: true } $ out/Debug/node --cpu-prof test/fixtures/workload/fibonacci.js 9227465
@gengjiawen Not until https://chromium-review.googlesource.com/c/v8/v8/+/1575698 is landed but it depends on GC to reproduce so it could disappear at times
@nodejs/v8-update I think it would take a while for https://chromium-review.googlesource.com/c/v8/v8/+/1575698 to roll back into master. Should we cherry pick this? It does reproduce on master in tests, we only disabled a particular build config that is more likely to trigger the crash.
Sure. Anything can be cherry-picked if there is a good reason for it.
Reacted by Joyee Cheung- added a commit that references this issue
on Apr 26, 2019 - added 2 commits that reference this issue
on Apr 29, 2019 - added a commit that references this issue
on Jul 27, 2026
This currently fails the debug build on master, the CPU profiler crashes when code cache is enabled (for some reason,
thisinv8::internal::ProfilerListener::InferScriptNameturns into a nullptr in the middle of the profiling).See stack trace
It does not crash if I build it with
code_cache_stub.cc, or build it in release mode.cc @nodejs/v8 @nodejs/v8-inspector @psmarshall