JsonStringify Reached heap limit Allocation failed - JavaScript heap out of memory

[meesha81]

Version

v16.9.0

Platform

Linux hostname 4.18.0-338.el8.x86_64 #1 SMP Fri Aug 27 17:32:14 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Subsystem

No response

What steps will reproduce the bug?

I am not sure how to directly reproduce bug.

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

First time issue. I am not able to detect which usage of JSON.stringify caused this bug. It would be nice to be able get "file/line" of call JSON.stringify - if bug caused because of toxic content for stringify.

What is the expected behavior?

Try to do not crash app, but do some log connected to script name/line number.

What do you see instead?

Internal crash of whole app with no information where to find out cause of the problem.

Additional information

Sep 30 11:35:15 aplsrv1 node[14037]: [14037:0x54787d0] 315562527 ms: Mark-sweep (reduce) 1871.9 (2076.2) -> 1871.6 (2075.7) MB, 35.4 / 0.0 ms (average mu = 0.796, current mu = 0.217) allocation failure scavenge might not succeed
Sep 30 11:35:15 aplsrv1 node[14037]: [14037:0x54787d0] 315562575 ms: Mark-sweep (reduce) 1872.6 (2075.7) -> 1872.5 (2076.7) MB, 46.4 / 0.0 ms (average mu = 0.671, current mu = 0.035) allocation failure scavenge might not succeed
Sep 30 11:35:15 aplsrv1 node[14037]: <--- JS stacktrace --->
Sep 30 11:35:15 aplsrv1 node[14037]: FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
Sep 30 11:35:15 aplsrv1 node[14037]: 1: 0xafcff0 node::Abort() [/usr/local/bin/node]
Sep 30 11:35:15 aplsrv1 node[14037]: 2: 0xa14113 node::FatalError(char const*, char const*) [/usr/local/bin/node]
Sep 30 11:35:15 aplsrv1 node[14037]: 3: 0xce5c7e v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [/usr/local/bin/node]
Sep 30 11:35:15 aplsrv1 node[14037]: 4: 0xce5ff7 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/usr/local/bin/node]
Sep 30 11:35:15 aplsrv1 node[14037]: 5: 0xeb4495 [/usr/local/bin/node]
Sep 30 11:35:15 aplsrv1 node[14037]: 6: 0xec3c11 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/usr/local/bin/node]
Sep 30 11:35:15 aplsrv1 node[14037]: 7: 0xec67be v8::internal::Heap::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/usr/local/bin/node]
Sep 30 11:35:15 aplsrv1 node[14037]: 8: 0xe87f22 v8::internal::Factory::AllocateRaw(int, v8::internal::AllocationType, v8::internal::AllocationAlignment) [/usr/local/bin/node]
Sep 30 11:35:15 aplsrv1 node[14037]: 9: 0xe80584 v8::internal::FactoryBasev8::internal::Factory::AllocateRawWithImmortalMap(int, v8::internal::AllocationType, v8::internal::Map, v8::internal::AllocationAlignment) [/usr/local/bin/node]
Sep 30 11:35:15 aplsrv1 node[14037]: 10: 0xe825f1 v8::internal::FactoryBasev8::internal::Factory::NewRawTwoByteString(int, v8::internal::AllocationType) [/usr/local/bin/node]
Sep 30 11:35:15 aplsrv1 node[14037]: 11: 0x1255bec v8::internal::IncrementalStringBuilder::Extend() [/usr/local/bin/node]
Sep 30 11:35:15 aplsrv1 node[14037]: 12: 0xfab59d v8::internal::JsonStringifier::SerializeString(v8::internal::Handlev8::internal::String) [/usr/local/bin/node]
Sep 30 11:35:15 aplsrv1 node[14037]: 13: 0xfaabc9 v8::internal::JsonStringifier::SerializeString(v8::internal::Handlev8::internal::String) [/usr/local/bin/node]
Sep 30 11:35:15 aplsrv1 node[14037]: 14: 0xfad411 v8::internal::JsonStringifier::Result v8::internal::JsonStringifier::Serialize_(v8::internal::Handlev8::internal::Object, bool, v8::internal::Handlev8::internal::Object) [/usr/local/bin/node]
Sep 30 11:35:15 aplsrv1 node[14037]: 15: 0xfae1f5 v8::internal::JsonStringifier::Result v8::internal::JsonStringifier::Serialize_(v8::internal::Handlev8::internal::Object, bool, v8::internal::Handlev8::internal::Object) [/usr/local/bin/node]
Sep 30 11:35:15 aplsrv1 node[14037]: 16: 0xfae1f5 v8::internal::JsonStringifier::Result v8::internal::JsonStringifier::Serialize_(v8::internal::Handlev8::internal::Object, bool, v8::internal::Handlev8::internal::Object) [/usr/local/bin/node]
Sep 30 11:35:15 aplsrv1 node[14037]: 17: 0xfae1f5 v8::internal::JsonStringifier::Result v8::internal::JsonStringifier::Serialize_(v8::internal::Handlev8::internal::Object, bool, v8::internal::Handlev8::internal::Object) [/usr/local/bin/node]
Sep 30 11:35:15 aplsrv1 node[14037]: 18: 0xfb0e71 v8::internal::JsonStringifier::Result v8::internal::JsonStringifier::Serialize_(v8::internal::Handlev8::internal::Object, bool, v8::internal::Handlev8::internal::Object) [/usr/local/bin/node]
Sep 30 11:35:15 aplsrv1 node[14037]: 19: 0xfb275f v8::internal::JsonStringify(v8::internal::Isolate*, v8::internal::Handlev8::internal::Object, v8::internal::Handlev8::internal::Object, v8::internal::Handlev8::internal::Object) [/usr/local/bin/node]
Sep 30 11:35:15 aplsrv1 node[14037]: 20: 0xd7b425 v8::internal::Builtin_JsonStringify(int, unsigned long*, v8::internal::Isolate*) [/usr/local/bin/node]
Sep 30 11:35:15 aplsrv1 node[14037]: 21: 0x15e68d9 [/usr/local/bin/node]
Sep 30 11:35:15 aplsrv1 systemd-coredump[1917871]: Resource limits disable core dumping for process 14037 (node).
Sep 30 11:35:15 aplsrv1 systemd-coredump[1917871]: Process 14037 (node) of user 48 dumped core.

[iam-frankqiu]

Could you add more info or steps about what you did that lead to this error? It may helper for us to solve the problem. Thank you.

[meesha81]

I would like to provide more information, but this is the first occur. Because of several places where we use JSON.stringify we are not able to detect where this bug coming from. From our application log we do not see anything strange. It can be caused because of some infinity object - some recured data). Propaby we should test all object before JSON.stringify to find out "big data" before to be able find out the place where it is coming from.

From our graphs, we know that this bug was not caused because of some memory leaks based on long time app running .
This bug caused by one strange request - but we are not able to find out which one from other app/nginx l logs.

[reduardo7]

Probably related with #40014?

[Danielv123]

Probably related with #40014?

Very unlikely.

[walderich]

I experienced the exact same error yesterday. And I also have the same issue as the author, not having any clue where to start looking for the source of the overflow. Is there anything we can do to improve the output, like enabling more output via switches or the like?

[Danielv123]

@walderich In my case I simply added a console.log() above every call to JSON stringify to track it down.