Segmentation Fault When Creating Heap Snapshot

[DakotaLarson]

• Platform:Linux vps.server.com 3.10.0-1160.25.1.el7.x86_64 deps: update openssl to 1.0.1j #1 SMP Wed Apr 28 21:49:45 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux AND Microsoft Windows NT 10.0.19041.0 x64
• Version: 14.17.2

What steps will reproduce the bug?

This issue can be reproduced on both Windows and CentOS 7, but only with the exact program I have, which isn't open source unfortunately.

How often does it reproduce? Is there a required condition?

This reproduces every time I attempt to create a snapshot. I have found the offending code is a while loop in an async function (There is an async call in the while loop).
When the logic is removed, the snapshot is created. Additionally, when the async call in the while loop is replaced with a "wait" function (https://pastebin.com/ff5mjjby), the same seg fault is produced.

What is the expected behavior?

When I create a heap snapshot using Chrome Devtools or the function available in WebStorm, I expect it to not create a seg fault.

What do you see instead?

When I create a heap snapshot, the program exits. I get this error in the console: https://pastebin.com/Z5936NF6. I get a similar message on CentOS.

Additional information

I know it's probably a long shot, but I hope this error message and program detail is enough to hypothesize a solution. Please let me know if there is any specific information I can provide to make this more understandable.

Of course, the offending code is integral to the program :/

All packages have been updated as well.

[lukas-bluescape]

I also ran into something very similar, which looks like the same problem and root cause, when attempting to take a heap snapshot with Node v14.15.5 on Ubuntu 20.04 (EDIT: Also built the latest node at commit ce4d224 from the v14.x branch and hit exactly the same problem with the same stacktrace as below).

Managed to pull the following out of the core file, showing the segfault happening in v8::internal::V8HeapExplorer:

Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0000000000fdd0ee in v8::internal::V8HeapExplorer::ExtractContextReferences(v8::internal::HeapEntry*, v8::internal::Context) ()
[Current thread is 1 (Thread 0x7fa4e8fe5780 (LWP 30))]
(gdb) bt
#0  0x0000000000fdd0ee in v8::internal::V8HeapExplorer::ExtractContextReferences(v8::internal::HeapEntry*, v8::internal::Context) ()
#1  0x0000000000fdfbca in v8::internal::V8HeapExplorer::IterateAndExtractReferences(v8::internal::HeapSnapshotGenerator*) ()
#2  0x0000000000fe0ac8 in v8::internal::HeapSnapshotGenerator::GenerateSnapshot() ()
#3  0x0000000000fd0d94 in v8::internal::HeapProfiler::TakeSnapshot(v8::ActivityControl*, v8::HeapProfiler::ObjectNameResolver*, bool) ()
#4  0x00000000009b4ed6 in node::heap::CreateHeapSnapshotStream(v8::FunctionCallbackInfo<v8::Value> const&) ()
#5  0x0000000000be571b in v8::internal::MaybeHandle<v8::internal::Object> v8::internal::(anonymous namespace)::HandleApiCallHelper<false>(v8::internal::Isolate*, v8::internal::Handle<v8::internal::HeapObject>, v8::internal::Handle<v8::internal::HeapObject>, v8::internal::Handle<v8::internal::FunctionTemplateInfo>, v8::internal::Handle<v8::internal::Object>, v8::internal::BuiltinArguments) ()
#6  0x0000000000be6cc6 in v8::internal::Builtin_Impl_HandleApiCall(v8::internal::BuiltinArguments, v8::internal::Isolate*) ()
#7  0x0000000000be7346 in v8::internal::Builtin_HandleApiCall(int, unsigned long*, v8::internal::Isolate*) ()
#8  0x0000000001401319 in Builtins_CEntry_Return1_DontSaveFPRegs_ArgvOnStack_BuiltinExit ()
#9  0x000000000139a5c2 in Builtins_InterpreterEntryTrampoline ()
#10 0x0000288f4c740471 in ?? ()
#11 0x000014043dc38179 in ?? ()
...

[DakotaLarson]

Hey @lukas-bluescape, thanks for taking a look at this. When you ran into the issue, was there anything you were able to do to remedy the behavior?

[lukas-bluescape]

@DakotaLarson: Unfortunately I haven't found a way to remedy this in my particular case. There's also a discussion in #38961 and #38985 about this same crash, but no resolution yet.

I did try with a debug build of node and managed to get some additional details from the core file. Maybe this might be useful to somebody else who knows their way around this codebase better?:

Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0000561128b72320 in v8::internal::heap_internals::MemoryChunk::GetHeap (this=0x100000000)
    at ../deps/v8/src/heap/heap-write-barrier-inl.h:82
82	    Heap* heap = *reinterpret_cast<Heap**>(reinterpret_cast<Address>(this) +
[Current thread is 1 (Thread 0x7faf295e2780 (LWP 30))]
(gdb) bt
#0  0x0000561128b72320 in v8::internal::heap_internals::MemoryChunk::GetHeap (this=0x100000000)
    at ../deps/v8/src/heap/heap-write-barrier-inl.h:82
#1  v8::internal::GetHeapFromWritableObject (object=...) at ../deps/v8/src/execution/isolate-utils-inl.h:38
#2  v8::internal::ReadOnlyHeap::GetReadOnlyRoots (object=...) at ../deps/v8/src/heap/read-only-heap-inl.h:25
#3  0x00005611293aa293 in v8::internal::HeapObject::GetReadOnlyRoots (this=<optimized out>)
    at ../deps/v8/src/objects/objects-inl.h:691
#4  v8::internal::HeapObject::IsUndefined (this=<optimized out>) at ../deps/v8/src/objects/objects-inl.h:117
#5  v8::internal::Context::has_extension (this=0x7fff4f67a3e8) at ../deps/v8/src/objects/contexts-inl.h:99
#6  v8::internal::Context::has_extension (this=0x7fff4f67a3e8) at ../deps/v8/src/objects/contexts-inl.h:98
#7  v8::internal::V8HeapExplorer::ExtractContextReferences (this=this@entry=0x7fff4f67a6a8, entry=entry@entry=0x561134c04738, 
    context=...) at ../deps/v8/src/profiler/heap-snapshot-generator.cc:1000
#8  0x00005611293ab5e8 in v8::internal::V8HeapExplorer::ExtractReferences (this=this@entry=0x7fff4f67a6a8, 
    entry=entry@entry=0x561134c04738, obj=...) at ../deps/v8/src/objects/contexts-inl.h:48
#9  0x00005611293aba92 in v8::internal::V8HeapExplorer::IterateAndExtractReferences (this=this@entry=0x7fff4f67a6a8, 
    generator=generator@entry=0x7fff4f67a690) at ../deps/v8/src/profiler/heap-snapshot-generator.cc:1516
#10 0x00005611293ace2f in v8::internal::HeapSnapshotGenerator::FillReferences (this=0x7fff4f67a690)
    at ../deps/v8/src/profiler/heap-snapshot-generator.cc:2094
#11 v8::internal::HeapSnapshotGenerator::GenerateSnapshot (this=this@entry=0x7fff4f67a690)
    at ../deps/v8/src/profiler/heap-snapshot-generator.cc:2058
#12 0x00005611293952f0 in v8::internal::HeapProfiler::TakeSnapshot (this=0x56112e0ab480, control=0x0, resolver=0x0, 
    treat_global_objects_as_roots=<optimized out>) at ../deps/v8/src/profiler/heap-profiler.cc:75
#13 0x00005611288628ec in node::heap::CreateHeapSnapshotStream (args=...) at ../src/heap_utils.cc:360
#14 0x0000561128c4ca85 in v8::internal::FunctionCallbackArguments::Call (this=this@entry=0x7fff4f67aa10, handler=..., 
    handler@entry=...) at ../deps/v8/src/api/api-arguments-inl.h:158
#15 0x0000561128c4daa0 in v8::internal::(anonymous namespace)::HandleApiCallHelper<false> (
    isolate=isolate@entry=0x56112e08eb40, function=..., function@entry=..., new_target=..., new_target@entry=..., 
    fun_data=..., receiver=..., receiver@entry=..., args=...) at /usr/include/x86_64-linux-gnu/bits/string_fortified.h:34
#16 0x0000561128c51fd7 in v8::internal::Builtin_Impl_HandleApiCall (args=..., isolate=isolate@entry=0x56112e08eb40)
    at ../deps/v8/src/handles/handles.h:137
#17 0x0000561128c52e70 in v8::internal::Builtin_HandleApiCall (args_length=5, args_object=0x7fff4f67abb8, 
    isolate=0x56112e08eb40) at ../deps/v8/src/builtins/builtins-api.cc:129
#18 0x0000561129b118e0 in Builtins_CEntry_Return1_DontSaveFPRegs_ArgvOnStack_BuiltinExit ()
    at ../../deps/v8/../../deps/v8/src/builtins/promise-misc.tq:111
#19 0x0000561129910ae2 in Builtins_InterpreterEntryTrampoline () at ../../deps/v8/../../deps/v8/src/builtins/convert.tq:16
#20 0x00000002707c0471 in ?? ()
#21 0x000004d91c772321 in ?? ()

[lukas-bluescape]

@DakotaLarson: I'm not sure whether or not you require Node v14 in your particular case, but I was able to take a heap snapshot successfully (without any crashes) on Node v16. Just wanted to let you know in case that helps!

[legendecas]

Tracking in #42558.