SvelteKit: heap limit allocation failed after uploading source maps

[risalfajar]

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?

Sentry Saas (sentry.io)

Which SDK are you using?

@sentry/sveltekit

SDK Version

7.63.0

Framework Version

1.5.0

Link to Sentry event

No response

SDK Setup

if (import.meta.env.PROD) {
	Sentry.init({
		dsn             : "https://example.dsn",
		tracesSampleRate: 1.0,

		// This sets the sample rate to be 10%. You may want this to be 100% while
		// in development and sample at a lower rate in production
		replaysSessionSampleRate: 0.1,

		// If the entire session is not sampled, use the below sample rate to sample
		// sessions when an error occurs.
		replaysOnErrorSampleRate: 1.0,

		// If you don't want to use Session Replay, just remove the line below:
		integrations: [new Replay()],

		environment: "production",
		release: version
	})
}

// If you have a custom error handler, pass it to `handleErrorWithSentry`
export const handleError = import.meta.env.PROD ? handleErrorWithSentry() : null

Steps to Reproduce

1. Create SvelteKit app with adapter-static
2. Install Sentry using npx @sentry/wizard@latest -i sveltekit
3. Run vite build
4. Build success
5. Source maps upload success

Expected Result

The process finish normally, without any error.

Actual Result

...
[sentry-vite-plugin] Info: Successfully uploaded source maps.
[sentry-vite-plugin] Info: Successfully finalized release.

<--- Last few GCs --->

[12017:0x120040000]    22163 ms: Mark-sweep (reduce) 4066.9 (4142.7) -> 4063.2 (4140.2) MB, 1464.2 / 0.0 ms  (average mu = 0.128, current mu = 0.013) allocation failure; scavenge might not succeed
[12017:0x120040000]    23650 ms: Mark-sweep (reduce) 4066.3 (4143.2) -> 4063.2 (4140.2) MB, 1483.2 / 0.0 ms  (average mu = 0.065, current mu = 0.003) allocation failure; scavenge might not succeed


<--- JS stacktrace --->

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 0x1041e26e4 node::Abort() [/Users/risal/.nvm/versions/node/v18.17.0/bin/node]
 2: 0x1041e28c8 node::ModifyCodeGenerationFromStrings(v8::Local<v8::Context>, v8::Local<v8::Value>, bool) [/Users/risal/.nvm/versions/node/v18.17.0/bin/node]
 3: 0x10433960c v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/Users/risal/.nvm/versions/node/v18.17.0/bin/node]
 4: 0x1044e3ec4 v8::internal::EmbedderStackStateScope::EmbedderStackStateScope(v8::internal::Heap*, v8::internal::EmbedderStackStateScope::Origin, cppgc::EmbedderStackState) [/Users/risal/.nvm/versions/node/v18.17.0/bin/node]
 5: 0x1044e7ab0 v8::internal::Heap::CollectSharedGarbage(v8::internal::GarbageCollectionReason) [/Users/risal/.nvm/versions/node/v18.17.0/bin/node]
 6: 0x1044e4ac4 v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::internal::GarbageCollectionReason, char const*, v8::GCCallbackFlags) [/Users/risal/.nvm/versions/node/v18.17.0/bin/node]
 7: 0x1044e1dc4 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/Users/risal/.nvm/versions/node/v18.17.0/bin/node]
 8: 0x1044d6900 v8::internal::HeapAllocator::AllocateRawWithLightRetrySlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/Users/risal/.nvm/versions/node/v18.17.0/bin/node]
 9: 0x1044d7144 v8::internal::HeapAllocator::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/Users/risal/.nvm/versions/node/v18.17.0/bin/node]
10: 0x1044bc9a0 v8::internal::Factory::AllocateRaw(int, v8::internal::AllocationType, v8::internal::AllocationAlignment) [/Users/risal/.nvm/versions/node/v18.17.0/bin/node]
11: 0x1044b64f4 v8::internal::MaybeHandle<v8::internal::SeqOneByteString> v8::internal::FactoryBase<v8::internal::Factory>::NewRawStringWithMap<v8::internal::SeqOneByteString>(int, v8::internal::Map, v8::internal::AllocationType) [/Users/risal/.nvm/versions/node/v18.17.0/bin/node]
12: 0x1045e17d4 v8::internal::JsonParser<unsigned short>::MakeString(v8::internal::JsonString const&, v8::internal::Handle<v8::internal::String>) [/Users/risal/.nvm/versions/node/v18.17.0/bin/node]
13: 0x1045dffd4 v8::internal::JsonParser<unsigned short>::ParseJsonValue() [/Users/risal/.nvm/versions/node/v18.17.0/bin/node]
14: 0x1045df548 v8::internal::JsonParser<unsigned short>::Parse(v8::internal::Isolate*, v8::internal::Handle<v8::internal::String>, v8::internal::Handle<v8::internal::Object>) [/Users/risal/.nvm/versions/node/v18.17.0/bin/node]
15: 0x1043c7de8 v8::internal::Builtin_JsonParse(int, unsigned long*, v8::internal::Isolate*) [/Users/risal/.nvm/versions/node/v18.17.0/bin/node]
16: 0x104bad18c Builtins_CEntry_Return1_DontSaveFPRegs_ArgvOnStack_BuiltinExit [/Users/risal/.nvm/versions/node/v18.17.0/bin/node]
17: 0x10aa254f0 
18: 0x10aa2467c 
19: 0x104bf8738 Builtins_PromiseFulfillReactionJob [/Users/risal/.nvm/versions/node/v18.17.0/bin/node]
20: 0x104b5bc4c Builtins_RunMicrotasks [/Users/risal/.nvm/versions/node/v18.17.0/bin/node]
21: 0x104b363a4 Builtins_JSRunMicrotasksEntry [/Users/risal/.nvm/versions/node/v18.17.0/bin/node]
22: 0x104465d10 v8::internal::(anonymous namespace)::Invoke(v8::internal::Isolate*, v8::internal::(anonymous namespace)::InvokeParams const&) [/Users/risal/.nvm/versions/node/v18.17.0/bin/node]
23: 0x104466200 v8::internal::(anonymous namespace)::InvokeWithTryCatch(v8::internal::Isolate*, v8::internal::(anonymous namespace)::InvokeParams const&) [/Users/risal/.nvm/versions/node/v18.17.0/bin/node]
24: 0x1044663dc v8::internal::Execution::TryRunMicrotasks(v8::internal::Isolate*, v8::internal::MicrotaskQueue*, v8::internal::MaybeHandle<v8::internal::Object>*) [/Users/risal/.nvm/versions/node/v18.17.0/bin/node]
25: 0x10448cb44 v8::internal::MicrotaskQueue::RunMicrotasks(v8::internal::Isolate*) [/Users/risal/.nvm/versions/node/v18.17.0/bin/node]
26: 0x10448d2e0 v8::internal::MicrotaskQueue::PerformCheckpoint(v8::Isolate*) [/Users/risal/.nvm/versions/node/v18.17.0/bin/node]
27: 0x104128c4c node::InternalCallbackScope::Close() [/Users/risal/.nvm/versions/node/v18.17.0/bin/node]
28: 0x104128fd0 node::InternalMakeCallback(node::Environment*, v8::Local<v8::Object>, v8::Local<v8::Object>, v8::Local<v8::Function>, int, v8::Local<v8::Value>*, node::async_context) [/Users/risal/.nvm/versions/node/v18.17.0/bin/node]
29: 0x10413e36c node::AsyncWrap::MakeCallback(v8::Local<v8::Function>, int, v8::Local<v8::Value>*) [/Users/risal/.nvm/versions/node/v18.17.0/bin/node]
30: 0x1041e789c node::fs::FSReqCallback::Resolve(v8::Local<v8::Value>) [/Users/risal/.nvm/versions/node/v18.17.0/bin/node]
31: 0x1041e7fa8 node::fs::AfterNoArgs(uv_fs_s*) [/Users/risal/.nvm/versions/node/v18.17.0/bin/node]
32: 0x1041de654 node::MakeLibuvRequestCallback<uv_fs_s, void (*)(uv_fs_s*)>::Wrapper(uv_fs_s*) [/Users/risal/.nvm/versions/node/v18.17.0/bin/node]
33: 0x104b1219c uv__work_done [/Users/risal/.nvm/versions/node/v18.17.0/bin/node]
34: 0x104b15958 uv__async_io [/Users/risal/.nvm/versions/node/v18.17.0/bin/node]
35: 0x104b27f0c uv__io_poll [/Users/risal/.nvm/versions/node/v18.17.0/bin/node]
36: 0x104b15e28 uv_run [/Users/risal/.nvm/versions/node/v18.17.0/bin/node]
37: 0x1041296e0 node::SpinEventLoop(node::Environment*) [/Users/risal/.nvm/versions/node/v18.17.0/bin/node]
38: 0x10421f2d4 node::NodeMainInstance::Run() [/Users/risal/.nvm/versions/node/v18.17.0/bin/node]
39: 0x1041af338 node::LoadSnapshotDataAndRun(node::SnapshotData const**, node::InitializationResult const*) [/Users/risal/.nvm/versions/node/v18.17.0/bin/node]
40: 0x1041af5f0 node::Start(int, char**) [/Users/risal/.nvm/versions/node/v18.17.0/bin/node]
41: 0x19e45bf28 start [/usr/lib/dyld]
[1]    12003 abort      npm run build

[lforst]

Hi, thanks for reporting this. This is likely related to getsentry/sentry-javascript-bundler-plugins#352. We'll release a backport of that fix.

(note: I am not sure if we actually fixed this memory issue. It was just our best guess...)