Ignored issue of JavaScript heap out of memory

[ErrorEater]

I'm reopening the issue since it was silently swept under the rug last time. The issue of node crashing keeps happening for 5 months so far. If the node stays on for a long time (from few hours to a day, depending on the activity) eventually it crashes with "JavaScript heap out of memory" error.

Has anybody from the team reproduced it?

Related issue: https://github.com/NomicFoundation/hardhat/issues/2491

Mined empty block #15324825 with base fee 7
eth_getBalance (3)
Mined empty block range #15324826 to #15339626

<--- Last few GCs --->

[3084:000001BEE58F6CD0] 174942965 ms: Mark-sweep 510.5 (521.9) -> 509.5 (521.9) MB, 792.0 / 0.0 ms  (average mu = 0.973, current mu = 0.975) allocation failure scavenge might not succeed
[3084:000001BEE58F6CD0] 174974125 ms: Mark-sweep 510.6 (521.9) -> 509.6 (522.2) MB, 781.0 / 0.0 ms  (average mu = 0.974, current mu = 0.975) allocation failure scavenge might not succeed


<--- JS stacktrace --->

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
 1: 00007FF75C407A1F v8::internal::CodeObjectRegistry::~CodeObjectRegistry+114207
 2: 00007FF75C396096 DSA_meth_get_flags+65542
 3: 00007FF75C396F4D node::OnFatalError+301
 4: 00007FF75CCCB2CE v8::Isolate::ReportExternalAllocationLimitReached+94
 5: 00007FF75CCB58AD v8::SharedArrayBuffer::Externalize+781
 6: 00007FF75CB58C7C v8::internal::Heap::EphemeronKeyWriteBarrierFromCode+1468
 7: 00007FF75CB55D94 v8::internal::Heap::CollectGarbage+4244
 8: 00007FF75CB53710 v8::internal::Heap::AllocateExternalBackingStore+2000
 9: 00007FF75CB78296 v8::internal::Factory::NewFillerObject+214
10: 00007FF75C8AA765 v8::internal::DateCache::Weekday+1797
11: 00007FF75CD58FC1 v8::internal::SetupIsolateDelegate::SetupHeap+494417
12: 000001BEE77CAFF4

[github-actions[bot]]

This issue is also being tracked on Linear.

We use Linear to manage our development process, but we keep the conversations on Github.

LINEAR-ID: 69d73aab-671f-4e9b-8394-93bd8397d287

[fvictorio]

Closing in favor of #3471 for bookkeeping reasons.