search

audreyt / ethercalc

Node.js port of Multi-user SocialCalc
https://ethercalc.net
Other
2.96k stars 537 forks source link

Javascript Garbage Collector crashs with OOM (FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory) #763

Open doobry-systemli opened 3 years ago

doobry-systemli commented 3 years ago

Hello,

since three days, our ethercalc instance kept crashing with OOM errors:

Jul  5 23:03:53 host ethercalc[11060]: [11060:0x4580ad0] 218830091 ms: Mark-sweep 1370.1 (1418.8) -> 1356.5 (1420.1) MB, 1556.0 / 0.0 ms  (average mu = 0.133, current mu = 0.023) allocation failure scavenge
 might not succeed
Jul  5 23:03:53 host ethercalc[11060]: [11060:0x4580ad0] 218831587 ms: Mark-sweep 1372.4 (1420.1) -> 1358.8 (1421.1) MB, 1476.6 / 0.0 ms  (average mu = 0.076, current mu = 0.013) allocation failure scavenge
 might not succeed
Jul  5 23:03:53 host ethercalc[11060]: <--- JS stacktrace --->
Jul  5 23:03:53 host ethercalc[11060]: FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
Jul  5 23:03:53 host ethercalc[11060]:  1: 0xa24ed0 no0:0:0:0:0:0:0:0ort() [node]
Jul  5 23:03:53 host ethercalc[11060]:  2: 0x966115 no0:0:0:0:0:0:0:0talError(char const*, char const*) [node]
Jul  5 23:03:53 host ethercalc[11060]:  3: 0xb9acde v0:0:0:0:0:0:0:0Utils0:0:0:0:0:0:0:0ReportOOMFailure(v0:0:0:0:0:0:0:0internal0:0:0:0:0:0:0:0Isolate*, char const*, bool) [node]
Jul  5 23:03:53 host ethercalc[11060]:  4: 0xb9b057 v0:0:0:0:0:0:0:0internal0:0:0:0:0:0:0:0V0:0:0:0:0:0:0:0talProcessOutOfMemory(v0:0:0:0:0:0:0:0internal0:0:0:0:0:0:0:0Isolate*, char const*, bool) [node]
Jul  5 23:03:53 host ethercalc[11060]:  5: 0xd56ea5  [node]
Jul  5 23:03:53 host ethercalc[11060]:  6: 0xd57a2f  [node]
Jul  5 23:03:53 host ethercalc[11060]:  7: 0xd65abb v0:0:0:0:0:0:0:0internal0:0:0:0:0:0:0:0Heap0:0:0:0:0:0:0:0ollectGarbage(v0:0:0:0:0:0:0:0internal0:0:0:0:0:0:0:0llocationSpace, v0:0:0:0:0:0:0:0internal0:0:0:0:0:0:0:0GarbageCollectionReason, v0:0:0:0:0:0:0:0GCCallbackFlags) [node]
Jul  5 23:03:53 host ethercalc[11060]:  8: 0xd6967c v0:0:0:0:0:0:0:0internal0:0:0:0:0:0:0:0Heap0:0:0:0:0:0:0:0llocateRawWithRetryOrFailSlowPath(int, v0:0:0:0:0:0:0:0internal0:0:0:0:0:0:0:0llocationType, v0:0:0:0:0:0:0:0internal0:0:0:0:0:0:0:0llocationOrigin, v0:0:0:0:0:0:0:0internal0:0:0:0:0:0:0:0llocationAlignment) [node]
Jul  5 23:03:53 host ethercalc[11060]:  9: 0xd37d2b v0:0:0:0:0:0:0:0internal0:0:0:0:0:0:0:0tory0:0:0:0:0:0:0:0NewFillerObject(int, bool, v0:0:0:0:0:0:0:0internal0:0:0:0:0:0:0:0llocationType, v0:0:0:0:0:0:0:0internal0:0:0:0:0:0:0:0llocationOrigin) [node]
Jul  5 23:03:53 host ethercalc[11060]: 10: 0x108035f v0:0:0:0:0:0:0:0internal0:0:0:0:0:0:0:0Runtime_AllocateInYoungGeneration(int, unsigned long*, v0:0:0:0:0:0:0:0internal0:0:0:0:0:0:0:0Isolate*) [node]
Jul  5 23:03:53 host ethercalc[11060]: 11: 0x1427079  [node]

We were able to circumvent this by passing NodJS option --max-old-space-size=6144. But still, our system metrics show that ethercalc takes huge amounts of CPU cycles and much more memory for short periods since three days.

No system or ethercalc updates took place in the last days, so our best guess is that a particular spreadsheet with toxic content is rsponsible for this huge increase in required resources. Any idea how to further debug and how to figure out the bad spreadsheet?