[Bug]: Crash when nesting encodeURI with large .repeat() chains #7035

Activity

1. bendrissou

   added

   Bug

   on Jul 2, 2025
2. rhuanjl

   added

   By Design

   on Oct 10, 2025
3. rhuanjl commented on Oct 10, 2025

   

   rhuanjl

   on Oct 10, 2025

   Collaborator

   More actions

   This is just an out of memory - ChakraCore calls Abort when out of memory, this was a deliberate microsoft design choice a long time back. As CC is no longer maintained by microsoft we could consider an alternate handling of our of memory but is there safe way to continue execution when out of memory?
4. saksham-malhotra-27 commented on Dec 15, 2025

   

   saksham-malhotra-27

   on Dec 15, 2025

   More actions

   Hi @rhuanjl,
   I was thinking about this core dump issue with deeply nested encodeURI(...).repeat(...) calls.
   Would it be feasible to implement periodic memory pressure checks during operations like repeat() that can cause exponential growth?
   For instance, checking available memory at intervals during string allocation, and throwing a recoverable RangeError or Error if we detect we're approaching critical memory levels?
   This could provide graceful failure without fundamentally changing OOM behavior, though I understand there might be performance trade-offs.
   Thanks!
5. rhuanjl commented on Dec 15, 2025

   

   rhuanjl

   on Dec 15, 2025

   Last edited by rhuanjl

   Collaborator

   More actions

   Hi @rhuanjl, I was thinking about this core dump issue with deeply nested encodeURI(...).repeat(...) calls. Would it be feasible to implement periodic memory pressure checks during operations like repeat() that can cause exponential growth? For instance, checking available memory at intervals during string allocation, and throwing a recoverable RangeError or Error if we detect we're approaching critical memory levels? This could provide graceful failure without fundamentally changing OOM behavior, though I understand there might be performance trade-offs. Thanks!

   The issue here is all in the third . repeat(), it asks for something in the order of 127gb, I'm not sure there's ever a time reasonable javascript should be doing that... However a "graceful" error could be safe here as until you hit that third .repeat() nothing bad has occurred.

   Currently if an operation requires a memory allocation and the allocation cannot be done we abort.

   What we could do I suppose is instead something like this where X is something large but reasonable e.g. 100 mb (pseudo code):

   if (memoryNeeded > X)
   {
     if (canAllocate (X))
     {
       if (!canAllocate(memoryNeeded))
       {
         throw JavascriptOutOfMemory;
       }
     }
     else
     {
       abort();
     }
   }
   else
   {
     if (!canAllocate(memoryNeeded))
     {
       abort();
     }
   }
6. ppenzin commented on Dec 16, 2025

   

   ppenzin

   on Dec 16, 2025

   Member

   More actions

   This is far from the only issue when out of memory is exposed as abort, through there is a decent amount of code that throws or catches out of memory exceptions. @rhuanjl do you know what is the backstory for that?
7. rhuanjl commented on Dec 16, 2025

   

   rhuanjl

   on Dec 16, 2025

   Collaborator

   More actions

   This is far from the only issue when out of memory is exposed as abort, through there is a decent amount of code that throws or catches out of memory exceptions. @rhuanjl do you know what is the backstory for that?

   In this old issue one of the MS developers (Mike Holman) comments on it: #5921 (comment)

   If there's an out of memory you may be part way through setting up an object that for some reason required two allocations and hence have something in an inconsistent state. Part of the issue is that most memory allocation goes through one path whether it is in a "safe" place to fail or not and thus the "safe" approach is to always abort if a memory allocation cannot be done to avoid any inconsistent states.

   A more consistent approach may be to have every Entry point to C++ that's going to result in memory allocation check up front if enough memory exists and if not throw an out of memory there rather than waiting until an allocation fails but this would be a rather major re-write.
8. ppenzin commented on Dec 20, 2025

   

   ppenzin

   on Dec 20, 2025

   Member

   More actions

   Maybe a adding a new exception type for unrecoverable OOM would be an intermediate solution - though it would be a convention to not to actually try to recover.