Sveltekit - Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory

[MSDev201]

Is there an existing issue for this?

• I have checked for existing issues https://github.com/getsentry/sentry-javascript/issues
• I have reviewed the documentation https://docs.sentry.io/
• I am using the latest SDK release https://github.com/getsentry/sentry-javascript/releases

How do you use Sentry?

Self-hosted/on-premise

Which SDK are you using?

@sentry/sveltekit

SDK Version

7.100.1

Framework Version

Sveltekit 2.4.0

Link to Sentry event

No response

SDK Setup

vite.config.js

import { sveltekit } from "@sveltejs/kit/vite";
import { sentrySvelteKit } from "@sentry/sveltekit";

/** @type {import('vite').UserConfig} */
const config = {
    plugins: [
        sentrySvelteKit({
            autoUploadSourceMaps: true,
            sourceMapsUploadOptions: {
                cleanArtifacts: true,
                rewrite: false,
            },
        }),
        sveltekit(),
    ],
};
export default config;

Steps to Reproduce

1. Use npx @sentry/wizard@latest -i sveltekit and follow the prompts
2. Run vite build
3. Get heap out of memory error

We are having some circular dependencies in a few of our dependencies, not sure if this could cause the issue.

Expected Result

Vite build should finish with a success code and dont consume all of my memory.

Actual Result

Sourcemap and Release are successfully published and it looks like everything has finished successfully but right before stopping, it consumes infinite amount of memory. I tested with NODE_OPTIONS=--max-old-space-size=16384 but still get a 'out of memory' error.

getsentry/sentry-javascript#17 101.3 [***-vite-plugin] Info: Successfully uploaded source maps.
getsentry/sentry-javascript#17 102.5 [***-vite-plugin] Info: Successfully finalized release.
getsentry/sentry-javascript#17 128.4 
getsentry/sentry-javascript#17 128.4 <--- Last few GCs --->
getsentry/sentry-javascript#17 128.4 
getsentry/sentry-javascript#17 128.4 [41:0x5a2e330]   123431 ms: Scavenge (reduce) 2031.6 (2064.8) -> 2031.4 (2064.8) MB, 9.7 / 0.0 ms  (average mu = 0.259, current mu = 0.269) allocation failure; 
getsentry/sentry-javascript#17 128.4 [41:0x5a2e330]   123455 ms: Scavenge (reduce) 2034.7 (2068.1) -> 2034.7 (2068.3) MB, 20.5 / 0.0 ms  (average mu = 0.259, current mu = 0.269) allocation failure; 
getsentry/sentry-javascript#17 128.4 [41:0x5a2e330]   123905 ms: Scavenge (reduce) 2035.4 (2069.0) -> 2035.4 (2069.0) MB, 5.0 / 0.0 ms  (average mu = 0.259, current mu = 0.269) allocation failure; 
getsentry/sentry-javascript#17 128.4 
getsentry/sentry-javascript#17 128.4 
getsentry/sentry-javascript#17 128.4 <--- JS stacktrace --->
getsentry/sentry-javascript#17 128.4 
getsentry/sentry-javascript#17 128.4 FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
getsentry/sentry-javascript#17 128.4  1: 0xbdd160 node::Abort() [node]
getsentry/sentry-javascript#17 128.4  2: 0xaf089c  [node]
getsentry/sentry-javascript#17 128.4  3: 0xdcc1d0 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [node]
getsentry/sentry-javascript#17 128.4  4: 0xdcc586 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [node]
getsentry/sentry-javascript#17 128.4  5: 0xfcb005  [node]
getsentry/sentry-javascript#17 128.4  6: 0xfcb5b6 v8::internal::Heap::RecomputeLimits(v8::internal::GarbageCollector) [node]
getsentry/sentry-javascript#17 128.4  7: 0xfdd8a6  [node]
getsentry/sentry-javascript#17 128.4  8: 0xfde4e5 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [node]
getsentry/sentry-javascript#17 128.4  9: 0xfba49f v8::internal::HeapAllocator::AllocateRawWithLightRetrySlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [node]
getsentry/sentry-javascript#17 128.4 10: 0xfbb4e7 v8::internal::HeapAllocator::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [node]
getsentry/sentry-javascript#17 128.4 11: 0xf9ac4a v8::internal::Factory::NewFillerObject(int, v8::internal::AllocationAlignment, v8::internal::AllocationType, v8::internal::AllocationOrigin) [node]
getsentry/sentry-javascript#17 128.4 12: 0x13ae67d v8::internal::Runtime_AllocateInOldGeneration(int, unsigned long*, v8::internal::Isolate*) [node]
getsentry/sentry-javascript#17 128.4 13: 0x18343f9  [node]
getsentry/sentry-javascript#17 128.8 Aborted (core dumped)
getsentry/sentry-javascript#17 ERROR: process "/bin/sh -c npm run build" did not complete successfully: exit code: 134

[Lms24]

Hi @MSDev201 thanks for writing in!

This is a somewhat known issue although we're not entirely sure what exactly is causing it. So far we've mostly pinned it down to

• specific libraries. Are you using Firebase by any chance? There's a version of the library that caused these issues (SvelteKit: heap limit allocation failed after uploading source maps #9383)
• a high number of large emitted bundles (sentry-vite-plugin cause javascript out of memory sentry-javascript-bundler-plugins#512)

Unfortunately, we don't have a solution for this yet which is also the case because we haven't received a minimal reproducible example yet. If you're able to provide one, we can debug this further.

If you have a highly customized build config by any chance, I suggest removing a couple of plugins to try to narrow it down. Let me know if this helps!

[MSDev201]

@Lms24 I could narrow it down a little more.

The Issue is happening here https://github.com/getsentry/sentry-javascript/blob/a7097d9ba2a74b2cb323da0ef22988a383782ffb/packages/sveltekit/src/vite/sourceMaps.ts#L169C7-L169C14

First of all, Im not sure if its correct to not await the flattening of the source maps. All processes are over when the flattening still is happening.
My suggestion would be to change this line simply into:

for(const file of jsFiles) {
...
}

This doesnt solve the problem thoug but it makes more clear that the issue is not happening after the source maps are uploaded, but before.

To narrow it further down, I logged all files which where passed to sorcery. One of those files is a big 0.5mb js file with a 1mb source map. Sorcery appears to load also additional required source maps (possibly even circulating?) and I assume that this is where the out of memory error is caused.
I havent looked into sorcery yet, so im not sure what options are there to prevent such issues.

[Lms24]

First of all, Im not sure if its correct to not await the flattening of the source maps. All processes are over when the flattening still is happening.

oof you're completely right. This probably worked out by chance (more or less I'd guess), given the invocation of Sentry CLI to actually start uploading but it's definitely a bug. Thanks for flagging!
I opened #10602 to fix

I havent looked into sorcery yet, so im not sure what options are there to prevent such issues.

Hmm this is a good point. Originally, I added sorcery to flatten the weird sourcemaps created by the Node Adapter (#7811). Which adapter are you using @MSDev201? I wonder if we should simply scope flattening to the node adapter to avoid this for other ones.