Out of Memory in deoptimizeThisOnEventAtPath since rollup 2.49.0

[Cubelrti]

• Rollup Version: 2.49.0
• Operating System (or Browser): any
• Node Version (if applicable): any
• Link to reproduction (IMPORTANT, read below): https://replit.com/@Cubelrti/rollup-repro

Expected Behavior

Built with no error.

src/marked.js is copied from monaco-editor/esm/vs/base/common/marked/marked.js which is part of monaco-editor.

Tried enlarging node memory size by using --max-old-space-size=10240, still crashed.

Actual Behavior

Rollup run infinitely and finally crashed because of allocation failure.

<--- Last few GCs --->

[293:0x3acde90]    75191 ms: Scavenge 1021.8 (1024.3) -> 1021.4 (1024.5) MB, 10.4 / 0.0 ms  (average mu = 0.313, current mu = 0.307) allocation failure 
[293:0x3acde90]    75271 ms: Scavenge 1022.2 (1024.5) -> 1021.7 (1024.8) MB, 18.0 / 0.0 ms  (average mu = 0.313, current mu = 0.307) allocation failure 
[293:0x3acde90]    75375 ms: Scavenge 1022.5 (1024.8) -> 1022.0 (1025.0) MB, 34.0 / 0.0 ms  (average mu = 0.313, current mu = 0.307) allocation failure 


<--- JS stacktrace --->

==== JS stack trace =========================================

    0: ExitFrame [pc: 0x140de99]
Security context: 0x1af117c808d1 <JSObject>
    1: deoptimizeThisOnEventAtPath [0x3a5bb808069] [/home/runner/.npm/_npx/293/lib/node_modules/rollup/dist/shared/rollup.js:~4435] [pc=0x2c0c142d53a2](this=0x01a78ee00741 <ExpressionEntity map = 0xa69a479059>,0,0x01a78ee00581 <JSArray[1]>,0x03a5bb825031 <ExpressionEntity map = 0xa69a45af69>)
    2: addEntityToBeDeoptimized [0x3a5bb807ff9] [/home/runner/.npm/_npx...

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 0xa1a640 node::Abort() [node]
 2: 0xa1aa4c node::OnFatalError(char const*, char const*) [node]
 3: 0xb9a68e v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [node]
 4: 0xb9aa09 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [node]
 5: 0xd57c85  [node]
 6: 0xd58316 v8::internal::Heap::RecomputeLimits(v8::internal::GarbageCollector) [node]
 7: 0xd64bd5 v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [node]
 8: 0xd65a85 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [node]
 9: 0xd6853c v8::internal::Heap::AllocateRawWithRetryOrFail(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [node]
10: 0xd2ef5b v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationType, v8::internal::AllocationOrigin) [node]
11: 0x10716ec v8::internal::Runtime_AllocateInOldGeneration(int, unsigned long*, v8::internal::Isolate*) [node]
12: 0x140de99  [node]
Aborted (core dumped)
exit status 134

[lukastaegert]

I will have a look, could be a bug

[lukastaegert]

Thanks for spotting, fix here: #4091

[dlockhart]

I'm still seeing stack overflow errors in our builds that started with 2.49.0 but haven't been resolved with the fix to this issue in 2.50.0.

<--- Last few GCs --->
[6586:0x52ef950] 267832 ms: Mark-sweep (reduce) 2028.1 (2051.8) -> 2027.0 (2052.6) MB, 3050.3 / 0.0 ms (average mu = 0.145, current mu = 0.004) allocation failure scavenge might not succeed
[6586:0x52ef950] 270839 ms: Mark-sweep (reduce) 2028.8 (2051.8) -> 2027.7 (2052.8) MB, 2515.6 / 0.0 ms (average mu = 0.154, current mu = 0.163) allocation failure scavenge might not succeed
<--- JS stacktrace --->
FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
1: 0xa222f0 node::Abort() [node]
2: 0x96411f node::FatalError(char const*, char const*) [node]
3: 0xb97f1e v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [node]
4: 0xb98297 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [node]
5: 0xd52fd5 [node]
6: 0xd53b5f [node]
7: 0xd61beb v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [node]
8: 0xd657ac v8::internal::Heap::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [node]
9: 0xd33e5b v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationType, v8::internal::AllocationOrigin) [node]
10: 0x107c700 v8::internal::Runtime_AllocateInOldGeneration(int, unsigned long*, v8::internal::Isolate*) [node]
11: 0x1423279 [node]
Aborted (core dumped)

Link to our CI run if that's helpful:
https://travis-ci.com/github/Brightspace/brightspace-integration/builds/226837999

[lukastaegert]

Not really, a reproduction would be helpful. Otherwise I need to manually sift through your code which could take ages.

[lukastaegert]

So what is likely happening is that there is an infinite loop somewhere that spans several functions. I need to find out the code sample that triggers it.

[EtienneBruines]

I need to find out the code sample that triggers it.

@lukeapage would it make sense to reopen this issue? To help keep track of "ongoing" issues? 😄

[lukastaegert]

Without a reproduction there is nothing we can do, we do not even know if it is just an error on user side i.e. wrong Rollup version.

[lukastaegert]

So to repeat THIS ERROR WILL NOT BE FIXED WITHOUT YOUR HELP.

[EtienneBruines]

@lukeapage thank you for that helpful clarification. 👍

[dlockhart]

I need to find out the code sample that triggers it.

Understood. Two of us on our team each spent a whole day trying to narrow down what's causing this but didn't really end up anywhere -- so we had to pin Rollup at 2.48 and move on.

Our application is quite large with lots of 3rd party dependencies. Excluding any one of several parts of the application from the Rollup build stopped the overflow errors, but we weren't able to narrow things down to a single block of code.

We were pretty confused about why excluding different parts on their own would solve the problem. For example, if the build had file-a.js, file-b.js, file-c.js and file-d.js, excluding file-a.js on its own OR file-d.js on its own solves things. Of course it's not that simple since both file-a and file-d include things which include other things which include other things, and so on. A common denominator we noticed was mobx, and also potentially @createjs/easeljs but didn't get anywhere definitive unfortunately.

We are pretty sure it's not a user-side error with the wrong Rollup version though... 2.48 everything works and 2.49 and higher it fails.

[lukastaegert]

From what you describe, it could also be that you just hit a "regular" memory limit. Does

Tried enlarging node memory size by using --max-old-space-size=10240

have any positive effect for you? Note that you can use very large numbers here that exceed actual physical memory without issues.

Otherwise, if the code is public you can point me to what repo I have to check out and give me instructions how to build it and I can have a go.