OOM with CJK fonts after v5.16.13 when using Fonts API #15318
Description
Astro Info
Astro v5.16.15
Vite v6.4.1
Node v24.12.0
System Windows (x64)
Package Manager pnpm
Output static
Adapter none
Integrations none
If this issue only occurs in one browser, which browser is a problem?
No response
Describe the Bug
Astro v5.16.13 introduced a very helpful feature allowing developers to reuse fonts with satori via the Fonts API. However, I have encountered a severe memory leak and excessive memory consumption during the build process since this update.
I utilize multiple CJK fonts to provide comprehensive i18n support, which significantly increases the size of font files being processed.
During the build process, the heap memory usage climbs rapidly, exceeding 4GB, and eventually results in a JavaScript heap out of memory error.
The situation is even worse in my actual project which includes a custom font provider.
Error Logs
[9480:000001BA57DE6000] 19348 ms: Scavenge (interleaved) 4072.6 (4084.5) -> 4070.8 (4104.2) MB, pooled: 0 MB, 12.65 / 0.00 ms (average mu = 0.318, current mu = 0.296) allocation failure; [9480:000001BA57DE6000] 19979 ms: Mark-Compact (reduce) 4077.3 (4104.7) -> 4074.6 (4079.7) MB, pooled: 0 MB, 18.06 / 0.00 ms (+ 481.9 ms in 96 steps since start of marking, biggest step 5.7 ms, walltime since start of marking 521 ms) (average mu = 0.3 FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory ----- Native stack trace -----
1: 00007FF6D09FAD5F void __cdecl node::OnFatalError(char const * __ptr64,char const * __ptr64)+1343
2: 00007FF6D16432D7 public: class v8::MaybeLocal __cdecl v8::Function::NewInstance(class v8::Local,int,class v8::Local * __ptr64 const)const __ptr64+423
3: 00007FF6D1443997 private: __cdecl v8::base::AddressSpaceReservation::AddressSpaceReservation(void * __ptr64,unsigned __int64) __ptr64+322071
4: 00007FF6D14476A4 private: __cdecl v8::base::AddressSpaceReservation::AddressSpaceReservation(void * __ptr64,unsigned __int64) __ptr64+337700
5: 00007FF6D145663C protected: void __cdecl v8::internal::StrongRootAllocatorBase::deallocate_impl(unsigned __int64 * __ptr64,unsigned __int64) __ptr64+16604
6: 00007FF6D1455E7B protected: void __cdecl v8::internal::StrongRootAllocatorBase::deallocate_impl(unsigned __int64 * __ptr64,unsigned __int64) __ptr64+14619
7: 00007FF6D28BE7ED struct v8::base::MagicNumbersForDivision __cdecl v8::base::UnsignedDivisionByConstant(unsigned __int64,unsigned int)+2791357
8: 00007FF6D1441460 private: __cdecl v8::base::AddressSpaceReservation::AddressSpaceReservation(void * __ptr64,unsigned __int64) __ptr64+312544
9: 00007FF6D14C5139 public: __cdecl v8::Unlocker::~Unlocker(void) __ptr64+9273
10: 00007FF6D103AEB8 public: __cdecl v8::String::Value::~Value(void) __ptr64+142680
11: 000001BA1FE7733A
ELIFECYCLE Command failed with exit code 134.
This issue appears to be directly related to the changes in commit cb60ee1, which introduced the getFontBuffer() helper in astro:assets.
What's the expected result?
Memory should be managed efficiently during the font buffer retrieval process.
Link to Minimal Reproducible Example
Participation
- I am willing to submit a pull request for this issue.