Linux Debian 5.15.146.1-microsoft-standard-WSL2 #1 SMP Thu Jan 11 04:09:03 UTC 2024 x86_64 GNU/Linux
Subsystem
No response
What steps will reproduce the bug?
I cannot provide a minimum reproducible code, as it works usually. I just have 1 scenario that triggers the crash (coredump available), and I don't know why.
The crash occurs when the debugger tries to stop at a breakpoint. There is 1 function in our server code that triggers that crash, if the breakpoint is anywhere else, devtools works just fine.
That function is nothing special.
How often does it reproduce? Is there a required condition?
If the breakpoint in a specific function, it crashes 100% of the time. The bug doesn't occur anywhere else.
What is the expected behavior? Why is that the expected behavior?
No response
What do you see instead?
Coredump:
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000000000e4f47d in v8::internal::ScopeIterator::VisitLocalScope(std::function<bool (v8::internal::Handle<v8::internal::String>, v8::internal::Handle<v8::internal::Object>, v8::internal::ScopeIterator::ScopeType)> const&, v8::internal::ScopeIterator::Mode, v8::internal::ScopeIterator::ScopeType) const ()
[Current thread is 1 (Thread 0x7f65fefac7c0 (LWP 10473))]
Backtrace:
#0 0x0000000000e4f47d in v8::internal::ScopeIterator::VisitLocalScope(std::function<bool (v8::internal::Handle<v8::internal::String>, v8::internal::Handle<v8::internal::Object>, v8::internal::ScopeIterator::ScopeType)> const&, v8::internal::ScopeIterator::Mode, v8::internal::ScopeIterator::ScopeType) const ()
#1 0x0000000000e4fbc7 in v8::internal::ScopeIterator::ScopeObject(v8::internal::ScopeIterator::Mode) ()
#2 0x0000000000e41ad0 in v8::internal::DebugEvaluate::ContextBuilder::ContextBuilder(v8::internal::Isolate*, v8::internal::JavaScriptFrame*, int) ()
#3 0x0000000000e41d42 in v8::internal::DebugEvaluate::Local(v8::internal::Isolate*, v8::internal::StackFrameId, int, v8::internal::Handle<v8::internal::String>, bool) ()
#4 0x0000000000e51010 in v8::internal::DebugStackTraceIterator::Evaluate(v8::Local<v8::String>, bool) ()
#5 0x00000000013ae7c6 in v8_inspector::V8DebuggerAgentImpl::evaluateOnCallFrame(v8_inspector::String16 const&, v8_inspector::String16 const&, v8_crdtp::detail::ValueMaybe<v8_inspector::String16>, v8_crdtp::detail::ValueMaybe<bool>, v8_crdtp::detail::ValueMaybe<bool>, v8_crdtp::detail::ValueMaybe<bool>, v8_crdtp::detail::ValueMaybe<bool>, v8_crdtp::detail::ValueMaybe<bool>, v8_crdtp::detail::ValueMaybe<double>, std::unique_ptr<v8_inspector::protocol::Runtime::RemoteObject, std::default_delete<v8_inspector::protocol::Runtime::RemoteObject> >*, v8_crdtp::detail::PtrMaybe<v8_inspector::protocol::Runtime::ExceptionDetails>*) ()
#6 0x000000000163655f in v8_inspector::protocol::Debugger::DomainDispatcherImpl::evaluateOnCallFrame(v8_crdtp::Dispatchable const&) ()
#7 0x00000000013effcb in v8_crdtp::UberDispatcher::DispatchResult::Run() ()
#8 0x00000000013bbde0 in v8_inspector::V8InspectorSessionImpl::dispatchProtocolMessage(v8_inspector::StringView) ()
#9 0x0000000000c9027a in node::inspector::(anonymous namespace)::SameThreadInspectorSession::Dispatch(v8_inspector::StringView const&) ()
#10 0x0000000000ca9f31 in node::inspector::(anonymous namespace)::MainThreadSessionState::Dispatch(std::unique_ptr<v8_inspector::StringBuffer, std::default_delete<v8_inspector::StringBuffer> >) ()
#11 0x0000000000ca842e in void node::inspector::(anonymous namespace)::AnotherThreadObjectReference<node::inspector::(anonymous namespace)::MainThreadSessionState>::Apply<std::unique_ptr<v8_inspector::StringBuffer, std::default_delete<v8_inspector::StringBuffer> > >(node::inspector::(anonymous namespace)::MainThreadSessionState*, void (node::inspector::(anonymous namespace)::MainThreadSessionState::*)(std::unique_ptr<v8_inspector::StringBuffer, std::default_delete<v8_inspector::StringBuffer> >), std::unique_ptr<v8_inspector::StringBuffer, std::default_delete<v8_inspector::StringBuffer> >&) ()
#12 0x0000000000ca877e in node::inspector::MainThreadInterface::DispatchMessages() [clone .part.162] ()
#13 0x0000000000ca8b9a in node::CallbackQueue<void, node::Environment*>::CallbackImpl<node::inspector::MainThreadInterface::Post(std::unique_ptr<node::inspector::Request, std::default_delete<node::inspector::Request> >)::{lambda(node::Environment*)#1}>::Call(node::Environment*) ()
#14 0x0000000000b0a458 in node::Environment::RunAndClearInterrupts() ()
#15 0x0000000000c90dac in node::inspector::NodeInspectorClient::runMessageLoopOnPause(int) ()
#16 0x0000000001395115 in v8_inspector::V8Debugger::handleProgramBreak(v8::Local<v8::Context>, v8::Local<v8::Value>, std::vector<int, std::allocator<int> > const&, v8::base::EnumSet<v8::debug::BreakReason, int>, v8::debug::ExceptionType, bool) ()
#17 0x000000000139516a in v8_inspector::V8Debugger::BreakProgramRequested(v8::Local<v8::Context>, std::vector<int, std::allocator<int> > const&, v8::base::EnumSet<v8::debug::BreakReason, int>) ()
#18 0x0000000000e5ca02 in v8::internal::Debug::OnDebugBreak(v8::internal::Handle<v8::internal::FixedArray>, v8::internal::StepAction, v8::base::EnumSet<v8::debug::BreakReason, int>) ()
#19 0x0000000000e5cc30 in v8::internal::Debug::Break(v8::internal::JavaScriptFrame*, v8::internal::Handle<v8::internal::JSFunction>) ()
#20 0x00000000012d1c06 in v8::internal::Runtime_DebugBreakOnBytecode(int, unsigned long*, v8::internal::Isolate*) ()
(don't hesitate to ask me for the entire core file, or for any information you might need)
Version
18.18.2, 18.19.1
Platform
Linux Debian 5.15.146.1-microsoft-standard-WSL2 #1 SMP Thu Jan 11 04:09:03 UTC 2024 x86_64 GNU/Linux
Subsystem
No response
What steps will reproduce the bug?
I cannot provide a minimum reproducible code, as it works usually. I just have 1 scenario that triggers the crash (coredump available), and I don't know why.
The crash occurs when the debugger tries to stop at a breakpoint. There is 1 function in our server code that triggers that crash, if the breakpoint is anywhere else, devtools works just fine. That function is nothing special.
How often does it reproduce? Is there a required condition?
If the breakpoint in a specific function, it crashes 100% of the time. The bug doesn't occur anywhere else.
What is the expected behavior? Why is that the expected behavior?
No response
What do you see instead?
Coredump:
Backtrace:
(don't hesitate to ask me for the entire core file, or for any information you might need)
Additional information
No response