Repository navigation
Inaccurate windows stacktrace printer #53361
Description
Activity
- changed the title
[-]Inaccurate windows stacktracer printer[/-][+]Inaccurate windows stacktrace printer[/+]on Jun 6, 2024 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@nodejs/platform-windows
Does it reproduce on older Node.js Windows releases? Maybe there was a regression? Or has it never really worked?
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 particularreleaseflag incorporates the--with-ltcgoption, 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
releaseflag. 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.
Reacted by Chengzhong WuDoes 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.
Is there any resolution for this? From what I understand this is expected because of the
ltcg? Should we close it asWon't fix?I think we should disable windows stack trace printer if it is deemed to be inaccurate -- it is better to not provide incorrect information IMO.
My local build with
.\vcbuild.bat ltcgstill outputs correct stacktrace though.This issue has been marked as stale due to 210 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.This issue has been marked as stale due to 90 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.
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:
What do you see instead?
Actual stack trace:
Additional information
Only reproducible on Windows release build downloaded from https://nodejs.org/download/ and https://nodejs.org/dist/. Local
.\vcbuild.batbuild 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