JavaScript heap out of memory Error

Hello!

I am writing this because I encountered a problem while creating and managing a Next.js project.

Below are the package version information used in my project.

"@draft-js-plugins/editor": "^4.1.4",
"@draft-js-plugins/inline-toolbar": "^4.2.1",
"@draft-js-plugins/static-toolbar": "^4.1.4",
"@mdi/js": "^7.4.47",
"@mdi/react": "^1.6.1",
"@next/bundle-analyzer": "^14.2.5",
"@reduxjs/toolkit": "^2.2.0",
"@supabase/ssr": "^0.3.0",
"@supabase/supabase-js": "^2.43.5",
"bootstrap": "^5.3.3",
"bootstrap-icons": "^1.11.3",
"chroma-js": "^2.4.2",
"date-fns": "^3.3.1",
"draft-js": "^0.11.7",
"draft-js-export-html": "^1.4.1",
"formik": "^2.4.5",
"fs": "^0.0.1-security",
"immutability-helper": "^3.1.1",
"js-cookie": "^3.0.5",
"material-symbols": "^0.17.1",
"md5": "^2.3.0",
"multer": "^1.4.5-lts.1",
"next": "13.5.6",
"next-connect": "^0.12.0",
"nextjs-toploader": "^1.6.6",
"node-cmd": "^5.0.0",
"nodemailer": "^6.9.14",
"openai": "^4.28.4",
"parse": "^4.3.1",
"pdfjs-dist": "^4.4.168",
"quill": "^2.0.2",
"react": "^18",
"react-apexcharts": "^1.4.1",
"react-big-calendar": "^1.13.0",
"react-bootstrap": "^2.10.3",
"react-bootstrap-switch": "^15.5.3",
"react-calendar": "^5.0.0",
"react-csv": "^2.2.2",
"react-dnd": "^16.0.1",
"react-dnd-html5-backend": "^16.0.1",
"react-dom": "^18",
"react-draft-wysiwyg": "^1.15.0",
"react-feather": "^2.0.10",
"react-pdf": "^9.1.0",
"react-quill": "^2.0.0",
"react-redux": "^9.1.0",
"react-table": "^7.8.0",
"reactstrap": "^9.2.2",
"redux-persist": "^6.0.0",
"resize-observer-polyfill": "^1.5.1",
"sass": "^1.70.0",
"simplebar": "^6.2.5",
"simplebar-react": "^3.2.4",
"styled-components": "^6.1.11",
"yup": "^1.3.3",
"zod": "^3.22.4"

As you can see, the backend uses supabase.
There is no problem in initially building and running the server.

However, at some point, the following error occurs.

<--- Last few GCs --->

[20196:0x5fd03e0]  7787604 ms: Mark-sweep (reduce) 2035.4 (2066.3) -> 2034.9 (2067.0) MB, 710.7 / 0.0 ms  (average mu = 0.221, current mu = 0.022) allocation failure; scavenge might not succeed
[20196:0x5fd03e0]  7788619 ms: Mark-sweep (reduce) 2037.0 (2067.9) -> 2036.0 (2067.1) MB, 999.5 / 0.0 ms  (average mu = 0.111, current mu = 0.015) allocation failure; scavenge might not succeed


<--- JS stacktrace --->

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
 1: 0xb83f50 node::Abort() [next-router-worker]
 2: 0xa94834  [next-router-worker]
 3: 0xd647c0 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [next-router-worker]
 4: 0xd64b67 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [next-router-worker]
 5: 0xf42265  [next-router-worker]
 6: 0xf5474d v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [next-router-worker]
 7: 0xf2ee4e v8::internal::HeapAllocator::AllocateRawWithLightRetrySlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [next-router-worker]
 8: 0xf30217 v8::internal::HeapAllocator::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [next-router-worker]
 9: 0xf113ea v8::internal::Factory::NewFillerObject(int, v8::internal::AllocationAlignment, v8::internal::AllocationType, v8::internal::AllocationOrigin) [next-router-worker]
10: 0x12d674f v8::internal::Runtime_AllocateInYoungGeneration(int, unsigned long*, v8::internal::Isolate*) [next-router-worker]
11: 0x17035b9  [next-router-worker]

Firstly, do you know the cause of this error?

Second, manage the session through middleware.js


  // 특정 경로를 무시
  const ignoredPaths = [
    "/term-of-service", "/resetPassword", "/open-source-license"
  ];
  
  if (
    ignoredPaths.includes(reqPath) ||
      reqPath.startsWith('/auth') || reqPath.startsWith('/public') || reqPath.startsWith('/privacy')
  ) {
    return NextResponse.next();
  }
  
  const supabase = createClient();

  const accessToken = cookieStore.get('supabase.access_token')?.value
  const refreshToken = cookieStore.get('supabase.refresh_token')?.value

  if (!accessToken || !refreshToken) {
    const reqUrl = new URL(req.url);
    const redirectUrl = new URL('/auth/login', reqUrl.origin).href;
    return NextResponse.redirect(redirectUrl);
  }
  
  const { data: session, error: sessionError } = await supabase.auth.setSession({
    access_token: accessToken,
    refresh_token: refreshToken,
  });
  console.log(session, sessionError)

  if (sessionError || !session.session) {
    const reqUrl = new URL(req.url);
    const redirectUrl = new URL('/auth/login', reqUrl.origin).href;
    return NextResponse.redirect(redirectUrl);
  } else if (session.session || !sessionError) {
    const response = NextResponse.next();
    const maxAge = 60*60*24*30; // 30일
    response.cookies.set('supabase.access_token', session.session.access_token, { path: '/', maxAge });
    response.cookies.set('supabase.refresh_token', session.session.refresh_token, { path: '/', maxAge });
    return response;
  }

  return NextResponse.next();

Is there any chance that this method of use could be problematic?
I’m getting so frustrated that I can’t figure this out.
I’d appreciate any help, like this.

Hello @hgjo-nanumspacec.

It could be a build cache issue. Can you try re-deploying without the build cache? Alternatively, you can set an environment variable called VERCEL_FORCE_NO_BUILD_CACHE with the value set to 1 to your project and run a fresh build. Either option will let you skip Vercel’s build cache to rule that out as a possible cause.

I’ve also seen memory issues related to linters. With Next.js you can set eslint to ignoreDuringBuilds: next.config.js Options: eslint | Next.js

Please give those ideas a try and let me know whether either of them works for you.

From what they said it seems like the build process works, It could be processing huge amounts of data if someone does a large scale DB read and then filters the data in the lambda it can eat up huge amounts of memory I was shoving through node memory limits doing some data processing recently and with the limited memory overhead on the lambda it could be much easier to hit that limit. Looking through React-PDF can absolutely eat through a 2gb instance with memory that cannot be cleared by GC as it is in active use

2 Likes

Oops, I missed that part! I think you’ve got the right answer here.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.