Odd random failures in nodejs 16.14.2 on 9.2-STABLE/amd64

[Mike Pumford <mpumford%mudcovered.org.uk@localhost>]

Been using node 14 quite happily for a while and have now followed 
pkgsrc by switching to node 16. However I'm getting random startup 
failures when compiling my typescript code:

# 

# Fatal process OOM in Failed to reserve virtual memory for CodeRange 

# 


[1]   Trace/BPT trap (core dumped) tsc -p . 

error Command failed with exit code 133.

Analysing the resultant core gives:

(gdb) bt
#0  0x0000000005604bb4 in v8::base::OS::Abort() ()
#1  0x0000000004e64372 in 
v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) ()
#2  0x0000000004e64591 in 
v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char 
const*, bool) ()
#3  0x0000000005007930 in v8::internal::Heap::SetUp() ()
#4  0x0000000004f9c158 in 
v8::internal::Isolate::Init(v8::internal::SnapshotData*, 
v8::internal::SnapshotData*, bool) ()
#5  0x00000000053247e4 in 
v8::internal::Snapshot::Initialize(v8::internal::Isolate*) ()
#6  0x0000000004e89511 in v8::Isolate::Initialize(v8::Isolate*, 
v8::Isolate::CreateParams const&) ()
#7  0x0000000004b14825 in 
node::NodeMainInstance::NodeMainInstance(v8::Isolate::CreateParams*, 
uv_loop_s*, node::MultiIsolatePlatform*, 
std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, 
std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, 
std::char_traits<char>, std::allocator<char> > > > const&, 
std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, 
std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, 
std::char_traits<char>, std::allocator<char> > > > const&, 
std::vector<unsigned long, std::allocator<unsigned long> > const*) ()
#8  0x0000000004aa433a in node::Start(int, char**) ()
#9  0x0000000004a2da4d in ___start ()
#10 0x00007f7f6fe0e9f8 in ?? () from /usr/libexec/ld.elf_so

I don't think the problem is specific to the typescript compiler as I'm 
seeing similar random failures when starting up language server 
processes. However its much more difficult to grab console output from 
those failures.

This process was totally reliable with node 14.

Mike