Inaccurate windows stacktrace printer

[legendecas]

Version

v20.11.1

Platform

Microsoft Windows NT 10.0.19045.0 x64

Subsystem

debug util

What steps will reproduce the bug?

One line quick reproduction:

$ node --max-heap-size=10 -e 'var idx = 0; while (true) {global[idx++] = new Array(10_000_000) }'

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

Always

What is the expected behavior? Why is that the expected behavior?

Expected stack trace:

 1: 00007FF73361E1CB node::DumpNativeBacktrace+155 [D:\dev\nodejs\node\src\debug_utils.cc]:L322
 2: 00007FF733554C24 node::OOMErrorHandler+324 [D:\dev\nodejs\node\src\node_errors.cc]:L621
 3: 00007FF73483A5D1 v8::Utils::ReportOOMFailure+33 [D:\dev\nodejs\node\deps\v8\src\api\api.cc]:L350
 4: 00007FF734821E96 v8::internal::V8::FatalProcessOutOfMemory+694 [D:\dev\nodejs\node\deps\v8\src\api\api.cc]:L302
 5: 00007FF7345952B0 v8::internal::Heap::FatalProcessOutOfMemory+32 [D:\dev\nodejs\node\deps\v8\src\heap\heap.cc]:L6314
 6: 00007FF734590CFD v8::internal::Heap::CollectGarbage+1229 [D:\dev\nodejs\node\deps\v8\src\heap\heap.cc]:L1967
 7: 00007FF7345AFEC4 v8::internal::HeapAllocator::AllocateRawWithLightRetrySlowPath+2084 [D:\dev\nodejs\node\deps\v8\src\heap\heap-allocator.cc]:L108
 8: 00007FF7345B0B5A v8::internal::HeapAllocator::AllocateRawWithRetryOrFailSlowPath+90 [D:\dev\nodejs\node\deps\v8\src\heap\heap-allocator.cc]:L124
 9: 00007FF7345C092D v8::internal::Factory::AllocateRaw+541 [D:\dev\nodejs\node\deps\v8\src\heap\factory.cc]:L284
10: 00007FF7345DDA1C v8::internal::FactoryBase<v8::internal::Factory>::NewFixedArray+108 [D:\dev\nodejs\node\deps\v8\src\heap\factory-base.cc]:L172

What do you see instead?

Actual stack trace:

 1: 00007FF73D0971AB node::SetCppgcReference+16075
 2: 00007FF73D00DCC6 v8::base::CPU::num_virtual_address_bits+79190
 3: 00007FF73D00FED5 v8::base::CPU::num_virtual_address_bits+87909
 4: 00007FF73DA7F061 v8::Isolate::ReportExternalAllocationLimitReached+65
 5: 00007FF73DA687F8 v8::Function::Experimental_IsNopFunction+1336
 6: 00007FF73D8CA120 v8::Platform::SystemClockTimeMillis+659328
 7: 00007FF73D8C71A8 v8::Platform::SystemClockTimeMillis+647176
 8: 00007FF73D8DC4BA v8::Platform::SystemClockTimeMillis+733978
 9: 00007FF73D8DCD37 v8::Platform::SystemClockTimeMillis+736151
10: 00007FF73D8E596E v8::Platform::SystemClockTimeMillis+772046

Additional information

Only reproducible on Windows release build downloaded from https://nodejs.org/download/ and https://nodejs.org/dist/. Local .\vcbuild.bat build can output correct stacktrace.

This is not related to #50849 since that only released in v20.12.0. This problem can reproduce on v20.11.1 and previous versions.

/cc @joyeecheung

[RedYetiDev]

Only reproducible on Windows release build downloaded

For comparison, here's the same command on Linux (v22.2.0):

└─$ node --max-heap-size=10 -e 'var idx = 0; while (true) {global[idx++] = new Array(10_000_000) }'

<--- Last few GCs --->
[3904:0x6790000]       90 ms: Mark-Compact 79.3 (80.7) -> 79.1 (81.7) MB, pooled: 0 MB, 40.29 / 0.00 ms  (average mu = 0.539, current mu = 0.539) allocation failure; scavenge might not succeed


<--- JS stacktrace --->

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
----- Native stack trace -----

 1: 0xe18f84 node::OOMErrorHandler(char const*, v8::OOMDetails const&) [node]
 2: 0x12102f0 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [node]
 3: 0x12105c7 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [node]
 4: 0x14400d5  [node]
 5: 0x1459949 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [node]
 6: 0x142e018 v8::internal::HeapAllocator::AllocateRawWithLightRetrySlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [node]
 7: 0x142ef45 v8::internal::HeapAllocator::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [node]
 8: 0x14072ae v8::internal::Factory::AllocateRaw(int, v8::internal::AllocationType, v8::internal::AllocationAlignment) [node]
 9: 0x13f592c v8::internal::FactoryBase<v8::internal::Factory>::AllocateRawArray(int, v8::internal::AllocationType) [node]
10: 0x13f6322 v8::internal::FactoryBase<v8::internal::Factory>::NewFixedArray(int, v8::internal::AllocationType) [node]
11: 0x15d57f6  [node]
12: 0x15ecdb2  [node]
13: 0x160d2e3  [node]
14: 0x16114e5 v8::internal::ArrayConstructInitializeElements(v8::internal::Handle<v8::internal::JSArray>, v8::internal::Arguments<(v8::internal::ArgumentsType)1>*) [node]
15: 0x185661d v8::internal::Runtime_NewArray(int, unsigned long*, v8::internal::Isolate*) [node]
16: 0x1f1e576  [node]
zsh: IOT instruction (core dumped)  node --max-heap-size=10 -e 

[targos]

@nodejs/platform-windows

[joyeecheung]

Does it reproduce on older Node.js Windows releases? Maybe there was a regression? Or has it never really worked?

[huseyinacacak-janea]

I'd like to share an observation regarding the Node.js build process. When preparing for a release or running it in the CI, we always use the command vcbuild release. This particular release flag incorporates the --with-ltcg option, which enables Link-Time Code Generation in the compiler. This optimization significantly reduces the executable size, approximately from 100MB down to 70MB.

However, it's important to note that this optimization may result in a more concise stack trace compared to builds created without the release flag. While this is a trade-off, the benefits of a smaller executable can be quite substantial, especially for deployment and distribution.

I've checked all the supported versions of Node.js (v18, v20, v22 and the v23-pre) and they all behave the same way.

[legendecas]

Does it reproduce on older Node.js Windows releases? Maybe there was a regression? Or has it never really worked?

Yes, this can also reproduce on older Node.js releases, but with slightly different stack traces. I think it never really worked properly.