Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory #669

Open
alirzayev-clopos opened this issue Sep 10, 2024 · 8 comments

Comments

@alirzayev-clopos
Copy link

Environment

"react": "^18.2.0",
"react-dom": "^18.2.0",
"@sentry/vite-plugin": "^2.22.4",
"@sentry/react": "^7.20.1",
"@sentry/tracing": "^6.12.0",

Instance: self-hosted

vite.config.ts:

sentryVitePlugin({
    org: "example",
    project: "example",
    url: "https://sentry.example.org/",
    sourcemaps: {
        ignore: ["node_modules"],
    },
}),

Steps to Reproduce

  1. Followed https://docs.sentry.io/platforms/javascript/sourcemaps/uploading/vite/ documentation to upload sourcemaps of existing project to Sentry. I have used Automatic setup.
  2. Run tsc && vite build

Expected Result

Sourcemaps uploaded to sentry.

Actual Result

<--- Last few GCs --->

[32764:0x138008000]    24925 ms: Scavenge (interleaved) 4042.2 (4129.8) -> 4041.5 (4130.5) MB, pooled: 0 MB, 10.46 / 0.00 ms  (average mu = 0.392, current mu = 0.345) allocation failure; 
[32764:0x138008000]    27305 ms: Mark-Compact 4051.8 (4139.5) -> 4049.3 (4149.0) MB, pooled: 0 MB, 2365.50 / 0.00 ms  (average mu = 0.171, current mu = 0.045) allocation failure; scavenge might not succeed


<--- JS stacktrace --->

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
----- Native stack trace -----

 1: 0x10467ff54 node::OOMErrorHandler(char const*, v8::OOMDetails const&) [/opt/homebrew/Cellar/node/22.5.1/bin/node]
 2: 0x10481e134 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [/opt/homebrew/Cellar/node/22.5.1/bin/node]
 3: 0x10481e0e8 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [/opt/homebrew/Cellar/node/22.5.1/bin/node]
 4: 0x1049c7094 v8::internal::Heap::CallGCPrologueCallbacks(v8::GCType, v8::GCCallbackFlags, v8::internal::GCTracer::Scope::ScopeId) [/opt/homebrew/Cellar/node/22.5.1/bin/node]
 5: 0x1049c5f10 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/opt/homebrew/Cellar/node/22.5.1/bin/node]
 6: 0x1049bc3d8 v8::internal::HeapAllocator::AllocateRawWithLightRetrySlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/opt/homebrew/Cellar/node/22.5.1/bin/node]
 7: 0x1049bcb44 v8::internal::HeapAllocator::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/opt/homebrew/Cellar/node/22.5.1/bin/node]
 8: 0x1049a3f8c v8::internal::Factory::NewFillerObject(int, v8::internal::AllocationAlignment, v8::internal::AllocationType, v8::internal::AllocationOrigin) [/opt/homebrew/Cellar/node/22.5.1/bin/node]
 9: 0x104cbd4ec v8::internal::Runtime_AllocateInYoungGeneration(int, unsigned long*, v8::internal::Isolate*) [/opt/homebrew/Cellar/node/22.5.1/bin/node]
10: 0x104471c74 Builtins_CEntry_Return1_ArgvOnStack_NoBuiltinExit [/opt/homebrew/Cellar/node/22.5.1/bin/node]
11: 0x1043dfe28 Builtins_GrowFastSmiOrObjectElements [/opt/homebrew/Cellar/node/22.5.1/bin/node]
12: 0x10de6c8c4 
13: 0x10de2ef30 
14: 0x10441d250 Builtins_LoadIC [/opt/homebrew/Cellar/node/22.5.1/bin/node]
15: 0x10de1b350 
16: 0x1044a4c04 Builtins_ArrayReduce [/opt/homebrew/Cellar/node/22.5.1/bin/node]
17: 0x10de75cfc 
18: 0x10de7778c 
19: 0x104419410 Builtins_AsyncFunctionAwaitResolveClosure [/opt/homebrew/Cellar/node/22.5.1/bin/node]
20: 0x1044e4578 Builtins_PromiseFulfillReactionJob [/opt/homebrew/Cellar/node/22.5.1/bin/node]
21: 0x104409714 Builtins_RunMicrotasks [/opt/homebrew/Cellar/node/22.5.1/bin/node]
22: 0x1043daaf4 Builtins_JSRunMicrotasksEntry [/opt/homebrew/Cellar/node/22.5.1/bin/node]
23: 0x104931918 v8::internal::(anonymous namespace)::Invoke(v8::internal::Isolate*, v8::internal::(anonymous namespace)::InvokeParams const&) [/opt/homebrew/Cellar/node/22.5.1/bin/node]
24: 0x104932020 v8::internal::(anonymous namespace)::InvokeWithTryCatch(v8::internal::Isolate*, v8::internal::(anonymous namespace)::InvokeParams const&) [/opt/homebrew/Cellar/node/22.5.1/bin/node]
25: 0x104955828 v8::internal::MicrotaskQueue::RunMicrotasks(v8::internal::Isolate*) [/opt/homebrew/Cellar/node/22.5.1/bin/node]
26: 0x1049555b8 v8::internal::MicrotaskQueue::PerformCheckpointInternal(v8::Isolate*) [/opt/homebrew/Cellar/node/22.5.1/bin/node]
27: 0x104590b90 node::InternalCallbackScope::Close() [/opt/homebrew/Cellar/node/22.5.1/bin/node]
28: 0x1045910e8 node::InternalMakeCallback(node::Environment*, v8::Local<v8::Object>, v8::Local<v8::Object>, v8::Local<v8::Function>, int, v8::Local<v8::Value>*, node::async_context) [/opt/homebrew/Cellar/node/22.5.1/bin/node]
29: 0x1045a8b50 node::AsyncWrap::MakeCallback(v8::Local<v8::Function>, int, v8::Local<v8::Value>*) [/opt/homebrew/Cellar/node/22.5.1/bin/node]
30: 0x1046864a4 node::fs::FSReqCallback::Resolve(v8::Local<v8::Value>) [/opt/homebrew/Cellar/node/22.5.1/bin/node]
31: 0x104687e7c node::fs::AfterNoArgs(uv_fs_s*) [/opt/homebrew/Cellar/node/22.5.1/bin/node]
32: 0x104677180 node::MakeLibuvRequestCallback<uv_fs_s, void (*)(uv_fs_s*)>::Wrapper(uv_fs_s*) [/opt/homebrew/Cellar/node/22.5.1/bin/node]
33: 0x108a16dfc uv__work_done [/opt/homebrew/Cellar/libuv/1.48.0/lib/libuv.1.dylib]
34: 0x108a1a4a8 uv__async_io [/opt/homebrew/Cellar/libuv/1.48.0/lib/libuv.1.dylib]
35: 0x108a2a164 uv__io_poll [/opt/homebrew/Cellar/libuv/1.48.0/lib/libuv.1.dylib]
36: 0x108a1a93c uv_run [/opt/homebrew/Cellar/libuv/1.48.0/lib/libuv.1.dylib]
37: 0x104591990 node::SpinEventLoopInternal(node::Environment*) [/opt/homebrew/Cellar/node/22.5.1/bin/node]
38: 0x1046ca08c node::NodeMainInstance::Run(node::ExitCode*, node::Environment*) [/opt/homebrew/Cellar/node/22.5.1/bin/node]
39: 0x1046c9de0 node::NodeMainInstance::Run() [/opt/homebrew/Cellar/node/22.5.1/bin/node]
40: 0x10463cce0 node::Start(int, char**) [/opt/homebrew/Cellar/node/22.5.1/bin/node]
41: 0x18f17f154 start [/usr/lib/dyld]
sh: line 1: 32764 Abort trap: 6           vite build
@alirzayev-clopos
Copy link
Author

alirzayev-clopos commented Sep 10, 2024

Note: if I increase heap size with this command, it runs successfully. But I don't think that's a solution as it should be ok to run in low-memory servers like Github Actions.

NODE_OPTIONS=--max-old-space-size=14096 vite build

@chargome
Copy link
Member

hey @alirzayev-clopos thanks for writing in.

this is probably related to getsentry/sentry-javascript-bundler-plugins#512

Could you please check this issue and see if any of the hints there might resolve your problem?

@alirzayev-clopos
Copy link
Author

alirzayev-clopos commented Sep 12, 2024

Hey @chargome.

Yes, I have read that issue and they are related. But hints don't solve my problem.

  1. sourcemap: true without Sentry plugin builds successfully.
  2. I don't use Firebase.
  3. There is zero circular dependency in our project. We thought this could be the reason but solved all circular dependencies and tried to upload source maps. The result is the same - failure.
  4. Vite and sentry upgraded to the latest version. Same result.

I will export memory profile and provide.

@alirzayev-clopos
Copy link
Author

alirzayev-clopos commented Sep 12, 2024

I have captured the memory profile, and ironically, it finished build successfully. I guess profiler does not limit heap size, that's why it succeeds.

Image

Image

I can't share a memory profile as it contains source code which I don't have rights to share.

@chargome
Copy link
Member

@alirzayev-clopos thanks for that, when you inspect the profile, can you spot anything that seems way off that could give us a hint?

@alirzayev-clopos
Copy link
Author

@chargome, unfortunately no. Sizes seem too big but don't know if it is a problem. How can I help to solve this problem? Should I provide something else?

@chargome
Copy link
Member

@alirzayev-clopos without us inspecting the memory profile or creating a reproducible repo we cannot really debug this from our side I'm afraid.

@alirzayev-clopos
Copy link
Author

Okay. I will try my best to create a reproducible repo.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: No status
Development

No branches or pull requests

3 participants