Need to capture caller that triggers any form of OOM

[otoby]

My node-report captures looks like this

================================================================================
==== Node Report ===============================================================

Event: Allocation failed - JavaScript heap out of memory, location: "CALL_AND_RETRY_LAST"
Filename: node-report.20171124.170746.22912.001.txt
Dump event time:  2017/11/24 17:07:46
Module load time: 2017/11/24 08:18:08
Process ID: 22912
Command line: nodejs --max_old_space_size=4096 app.js

Node.js version: v8.9.1
(http_parser: 2.7.0, v8: 6.1.534.47, uv: 1.15.0, zlib: 1.2.11, ares: 1.10.1-DEV,
 modules: 57, nghttp2: 1.25.0, openssl: 1.0.2m, icu: 59.1, unicode: 9.0,
 cldr: 31.0.1, tz: 2017b)

node-report version: 2.2.1 (built against Node.js v8.9.1, glibc 2.23, 64 bit)

OS version: Linux 4.10.0-38-generic 16.04-Ubuntu SMP Tue Oct 10 16:32:20 UTC 2017
(glibc: 2.23)

Machine: Ubuntu-1604

================================================================================
==== JavaScript Stack Trace ====================================================

No stack trace available

================================================================================
==== Native Stack Trace ========================================================

 0: [pc=0x7fa82d1e62e3]  [/home/project/prod/node_modules/node-report/api.node]
 1: [pc=0xaea062] v8::Utils::ReportOOMFailure(char const*, bool) [nodejs]
 2: [pc=0xaea274] v8::internal::V8::FatalProcessOutOfMemory(char const*, bool) [nodejs]
 3: [pc=0xe5194b] v8::internal::Factory::NewRawOneByteString(int, v8::internal::PretenureFlag) [nodejs]
 4: [pc=0xfa2fe2] v8::internal::String::SlowFlatten(v8::internal::Handle<v8::internal::ConsString>, v8::internal::PretenureFlag) [nodejs]
 5: [pc=0xae7aec] v8::internal::String::Flatten(v8::internal::Handle<v8::internal::String>, v8::internal::PretenureFlag) [nodejs]
 6: [pc=0xb1555b] v8::String::WriteUtf8(char*, int, int*, int) const [nodejs]
 7: [pc=0x1298ee0] node::StringBytes::Write(v8::Isolate*, char*, unsigned long, v8::Local<v8::Value>, node::encoding, int*) [nodejs]
 8: [pc=0x123db1f] node::Buffer::New(v8::Isolate*, v8::Local<v8::String>, node::encoding) [nodejs]
 9: [pc=0x123dd24]  [nodejs]
10: [pc=0x2357061fe807] 

================================================================================
==== JavaScript Heap and Garbage Collector =====================================

Heap space name: new_space
    Memory size: 1,048,576 bytes, committed memory: 17,408 bytes
    Capacity: 1,031,168 bytes, used: 0 bytes, available: 1,031,168 bytes
Heap space name: old_space
    Memory size: 5,140,992,000 bytes, committed memory: 4,951,833,416 bytes
    Capacity: 4,360,313,520 bytes, used: 4,282,770,832 bytes, available: 77,542,688 bytes
Heap space name: code_space
    Memory size: 2,621,440 bytes, committed memory: 2,433,824 bytes
    Capacity: 2,156,512 bytes, used: 2,156,512 bytes, available: 0 bytes
Heap space name: map_space
    Memory size: 1,593,344 bytes, committed memory: 760,112 bytes
    Capacity: 529,848 bytes, used: 529,848 bytes, available: 0 bytes
Heap space name: large_object_space
    Memory size: 9,523,200 bytes, committed memory: 9,523,200 bytes
    Capacity: 9,464,352 bytes, used: 9,464,352 bytes, available: 0 bytes

Total heap memory size: 5,155,778,560 bytes
Total heap committed memory: 4,964,567,960 bytes
Total used heap memory: 4,294,921,544 bytes
Total available heap memory: 78,573,856 bytes

Heap memory limit: 4,328,521,728
`

Is there a way to enable the report above include any trace of where this occurred from Nodejs. Also, It does not have to be accurate.

[rnchamberlain]

Unfortunately there is no reliable way AFAIK to get a JavaScript stack trace from Node/V8 at the point when a fatal error has occurred - as in this case. Hence the empty JavaScript Stack Trace section in the report.

In practice the code that finally causes the OOM is often not the culprit. Getting a heap dump and examining that in the chrome developer tools is usually the best follow-up approach, now that you know it's using up an excessive (?) 4Gb in the old space.

[otoby]

Okay. Thank you @rnchamberlain