Angular on Azure DevOps running out of memory even with max_old_space_size set

Question

I have an angular project that I recently upgraded to Angular 13. This project is building in Azure DevOps.

About 1 in 3 builds fail due to memory issues. I get lots of different errors each run, but they all are about memory.

I have scoured the internet, and I have been using the max_old_space_size but that doesn't seem to solve my problem. Is there a better way to make the angular build actually use less memory during build?

Here are the 3 errors I often see. Note each run is different, and sometimes it builds fine.

##[error]Error(0,0): Error [main.5aa4446f2024043f.js: ;]DataCloneError: Data cannot be cloned, out of memory.
Error : Optimization error [main.5aa4446f2024043f.js]: DataCloneError: Data cannot be cloned, out of memory. [D:\a\1\s\MyApp\MyApp.Web\MyApp.Web.csproj]
      at WorkerInfo.postTask (D:\a\1\s\MyApp\MyApp.Web\ClientApp\node_modules\piscina\dist\src\index.js:305:23)
      at ThreadPool._onWorkerAvailable (D:\a\1\s\MyApp\MyApp.Web\ClientApp\node_modules\piscina\dist\src\index.js:518:24)
      at D:\a\1\s\MyApp\MyApp.Web\ClientApp\node_modules\piscina\dist\src\index.js:381:46
      at AsynchronouslyCreatedResourcePool.maybeAvailable (D:\a\1\s\MyApp\MyApp.Web\ClientApp\node_modules\piscina\dist\src\index.js:237:17)
      at WorkerInfo.onMessage (D:\a\1\s\MyApp\MyApp.Web\ClientApp\node_modules\piscina\dist\src\index.js:424:26)
      at WorkerInfo._handleResponse (D:\a\1\s\MyApp\MyApp.Web\ClientApp\node_modules\piscina\dist\src\index.js:289:14)
      at MessagePort.<anonymous> (D:\a\1\s\MyApp\MyApp.Web\ClientApp\node_modules\piscina\dist\src\index.js:258:51)
      at MessagePort.[nodejs.internal.kHybridDispatch] (node:internal/event_target:643:20)
      at MessagePort.exports.emitMessage (node:internal/per_context/messageport:23:28)

Another one here:

 #FailureMessage Object: 0000001D9D3F9EB0
  
  
  #
  # Fatal error in , line 0
  # Fatal process out of memory: Zone
  #
  #
  #
  #FailureMessage Object: 0000001D9D2FA470
   1: 00007FF783AF79CF public: __cdecl v8::internal::CodeObjectRegistry::~CodeObjectRegistry(void) __ptr64+114207
   2: 00007FF783A13E9F public: class std::basic_ostream<char,struct std::char_traits<char> > & __ptr64 __cdecl std::basic_ostream<char,struct std::char_traits<char> >::operator<<(__int64) __ptr64+65103
   3: 00007FF7846F26C2 void __cdecl V8_Fatal(char const * __ptr64,...)+162
   4: 00007FF7843A55DE public: void __cdecl v8::SharedArrayBuffer::Externalize(class std::shared_ptr<class v8::BackingStore> const & __ptr64) __ptr64+286
   5: 00007FF783F3FA57 private: unsigned __int64 __cdecl v8::internal::Zone::NewExpand(unsigned __int64) __ptr64+279
   6: 00007FF783D4EAE4 public: virtual char const * __ptr64 __cdecl disasm::NameConverter::NameOfXMMRegister(int)const __ptr64+17108
   7: 00007FF7847752F0 public: void __cdecl v8::internal::compiler::Schedule::AddGoto(class v8::internal::compiler::BasicBlock * __ptr64,class v8::internal::compiler::BasicBlock * __ptr64) __ptr64+48
   8: 00007FF7848E47D2 private: void __cdecl v8::internal::compiler::Scheduler::ComputeSpecialRPONumbering(void) __ptr64+3490
   9: 00007FF7848E3B88 private: void __cdecl v8::internal::compiler::Scheduler::ComputeSpecialRPONumbering(void) __ptr64+344
  10: 00007FF7848E752D private: static void __cdecl v8::internal::compiler::Scheduler::PropagateImmediateDominators(class v8::internal::compiler::BasicBlock * __ptr64)+3101
  11: 00007FF7848E29A5 private: void __cdecl v8::internal::compiler::Scheduler::BuildCFG(void) __ptr64+277
  12: 00007FF7848E380E public: static class v8::internal::compiler::Schedule * __ptr64 __cdecl v8::internal::compiler::Scheduler::ComputeSchedule(class v8::internal::Zone * __ptr64,class v8::internal::compiler::Graph * __ptr64,class v8::base::Flags<enum v8::internal::compiler::Scheduler::Flag,int>,class v8::internal::TickCounter * __ptr64,class v8::internal::ProfileDataFromFile const * __ptr64)+270
  13: 00007FF7847A2CA9 public: bool __cdecl v8::internal::compiler::LoopPeeler::CanPeel(class v8::internal::compiler::LoopTree::Loop * __ptr64) __ptr64+185
  14: 00007FF7847A83FB public: class v8::internal::compiler::LifetimePosition __cdecl v8::internal::compiler::LiveRange::NextStart(void)const __ptr64+2043
  15: 00007FF7847A3BC1 public: class v8::internal::compiler::LifetimePosition __cdecl v8::internal::compiler::LiveRange::End(void)const __ptr64+177
  16: 00007FF78433CFF1 public: enum v8::internal::CompilationJob::Status __cdecl v8::internal::OptimizedCompilationJob::ExecuteJob(class v8::internal::RuntimeCallStats * __ptr64,class v8::internal::LocalIsolate * __ptr64) __ptr64+49
  17: 00007FF78430DF49 private: void __cdecl v8::internal::OptimizingCompileDispatcher::CompileNext(class v8::internal::OptimizedCompilationJob * __ptr64,class v8::internal::LocalIsolate * __ptr64) __ptr64+57
  18: 00007FF78430EA1A public: void __cdecl v8::internal::OptimizingCompileDispatcher::QueueForOptimization(class v8::internal::OptimizedCompilationJob * __ptr64) __ptr64+714
  19: 00007FF783A1682D public: class std::basic_ostream<char,struct std::char_traits<char> > & __ptr64 __cdecl std::basic_ostream<char,struct std::char_traits<char> >::operator<<(__int64) __ptr64+75741
  20: 00007FF783B46EDD uv_poll_stop+557
  21: 00007FF784960120 public: class v8::internal::compiler::Operator const * __ptr64 __cdecl v8::internal::compiler::RepresentationChanger::Uint32OverflowOperatorFor(enum v8::internal::compiler::IrOpcode::Value) __ptr64+146416
  22: 00007FF80C834ED0 BaseThreadInitThunk+16
  23: 00007FF80D26E39B RtlUserThreadStart+43

One More:

 <--- Last few GCs --->
  
  [6640:000001CC0BCB3FC0]    21334 ms: Scavenge 87.4 (107.8) -> 78.6 (111.3) MB, 9.5 / 0.0 ms  (average mu = 0.992, current mu = 0.990) allocation failure 
  [6640:000001CC0BCB3FC0]    21397 ms: Scavenge 91.4 (111.8) -> 82.6 (115.5) MB, 21.7 / 0.0 ms  (average mu = 0.992, current mu = 0.990) allocation failure 
  [6640:000001CC0BCB3FC0]    21783 ms: Scavenge 95.6 (116.0) -> 86.7 (119.5) MB, 158.3 / 0.0 ms  (average mu = 0.992, current mu = 0.990) allocation failure 
  
  
  <--- JS stacktrace --->
  
  
  <--- Last few GCs --->
  
  [6640:000001CC0BCB3FC0]    21334 ms: Scavenge 87.4 (107.8) -> 78.6 (111.3) MB, 9.5 / 0.0 ms  (average mu = 0.992, current mu = 0.990) allocation failure 
  [6640:000001CC0BCB3FC0]    21397 ms: Scavenge 91.4 (111.8) -> 82.6 (115.5) MB, 21.7 / 0.0 ms  (average mu = 0.992, current mu = 0.990) allocation failure 
  [6640:000001CC0BCB3FC0]    21783 ms: Scavenge 95.6 (116.0) -> 86.7 (119.5) MB, 158.3 / 0.0 ms  (average mu = 0.992, current mu = 0.990) allocation failure 
  
  
  <--- JS stacktrace --->
  
  
  <--- Last few GCs --->
  
  [6640:000001CC0BD4A7B0]    21478 ms: Scavenge 56.2 (76.6) -> 47.2 (80.1) MB, 17.0 / 0.0 ms  (average mu = 0.996, current mu = 0.996) allocation failure 
  [6640:000001CC0BD4A7B0]    22725 ms: Scavenge 60.5 (80.8) -> 51.3 (82.6) MB, 1020.4 / 0.0 ms  (average mu = 0.996, current mu = 0.996) allocation failure 
  [6640:000001CC0BD4A7B0]    27389 ms: Scavenge 62.7 (83.1) -> 54.9 (85.6) MB, 1839.8 / 0.0 ms  (average mu = 0.996, current mu = 0.996) allocation failure 
  
  
  <--- JS stacktrace --->
  
##[error]EXEC(0,0): Error : MarkCompactCollector: young object promotion failed Allocation failed - JavaScript heap out of memory
EXEC : FATAL error : MarkCompactCollector: young object promotion failed Allocation failed - JavaScript heap out of memory [D:\a\1\s\BehaviorLive\BehaviorLive.Web\BehaviorLive.Web.csproj]
##[error]EXEC(0,0): Error : MarkCompactCollector: young object promotion failed Allocation failed - JavaScript heap out of memory
EXEC : FATAL error : MarkCompactCollector: young object promotion failed Allocation failed - JavaScript heap out of memory [D:\a\1\s\BehaviorLive\BehaviorLive.Web\BehaviorLive.Web.csproj]
##[error]EXEC(0,0): Error : MarkCompactCollector: young object promotion failed Allocation failed - JavaScript heap out of memory

Sardanapalus

Seems like your application code has some code that is causing memory leak. Please try to figure out the issue and try to fix the same. – Musso

@AnoopRajasekharaWarrier This isn't an error with the application, if you read the question it is happening during the build. – Sardanapalus

is it an ASP.net web application? why the front-end build was referring to a asp.net project file (D:\a\1\s\MyApp\MyApp.Web\MyApp.Web.csproj) – Boding

Yes. It is an asp.net core backend. The .csproj build triggers the angular build as is standard procedure with these apps – Sardanapalus

Answer 1

You didn't jot it down so I ask. Did you use command like:

cross-env NODE_OPTIONS=--max-old-space-size=8192 npm build

Unbeaten

Yes, I have used the max-old-space-size parameter for NPM and added it as an environment variable to the Azure Build and it doesn't help. Everything was fine before upgrading to angular 13. – Sardanapalus

do you have a lot of tests? angular add property about reusing components in test. – Unbeaten

No, I don't have any tests – Sardanapalus

Answer 2

It depends on the Azure Agent that you use for deployment. The memory available for the agent might not be enough to complete the build, especially when the agent is trying to process parallel jobs.

You can debug and find exactly what amount of memory will get the job done in your local system. You can start by keeping

max_old_space_size=1024

And increase size untill build succeeds. I found ours work with 2048.

Now if you can get a dedicated agent which can allocate atleast that amount of memory to run the job, then you will have a reliable solution.

EDIT - Another solution would be to try a different build tool. I assume you are using webpack, there could be other bundlers out there that are more efficient.

Vishnu