It's impossible to track this down without a reproduction.

Yeah I know. Before I was getting a memory heap around the generation of the sourcemaps so I removed it. And I got this error message around the native array file.

Is there some way to get a more verbose stack trace?

FYI it's now building but only because I added more memory to the node process:

NODE_OPTIONS="--max_old_space_size=4096"

It builds up to 28 routes but when I give 30 routes (we have 31 routes) the memory of the process goes up to 3GB of memory (and even more). I am running the build process on an average laptop that has 8GB of memory, some of it already used. But it managed.

I don't know if I should keep this issue open or not.
If it helps, here the stats of the built pages:

The process crashes when it tries to create the source maps (most of the times).

Really the only way we'll ever know is if a full reproduction is provided. I'll close this for now.

We too have noticed that after upgrading to Next 9 we are getting out of memory errors whereas with Next 8 this wasn't an issue.

In our case we are building our app in CircleCi as part of our CI flow and encountering the following:

Exited with code 137
Hint: Exit code 137 typically means the process is killed because it was running out of memory
Hint: Check if you can optimize the memory usage in your app
Hint: Max memory usage of this container is 4284268544
 according to /sys/fs/cgroup/memory/memory.max_usage_in_bytes

4GB is memory limit for a CircleCI container, hence the error. It appears building with Next 9 we are hitting that limit.

I don't have a reproducible case to share at the moment.

We also faced this problem while deploying my application with NextJs 9.

Out of the 3 projects that we upgraded to NextJs 9, two of them face ram usage problem when deploying to Elastic Beanstalk. End up we have to revert it. Unfortunately I don't have a repo to share to replicate the problem.

I'm getting the same out of memory issue, but mine occurs after all lambdas are built. I can finish the build on my laptop, but it crashes when deploying, however I've seen a few out of memory issue periodically while developing locally. The only thing recognizable (to me) is this line:

 readFile [/tmp/b0cc21aa63cece4e/.build-utils/.builder/node_modules/@now/next/dist/index.js:9555]

Here's the log...

Aug 22 2019 01:26:51:346 | λ  (Lambda)       page was emitted as a lambda (i.e. getInitialProps)
-- | --
Aug 22 2019 01:26:51:346 | ⚡  (Static File)  page was prerendered as static HTML
Aug 22 2019 01:26:51:434 | Done in 146.48s.
Aug 22 2019 01:26:51:444 | preparing lambda files...
Aug 22 2019 01:34:22:983 | <--- Last few GCs --->
Aug 22 2019 01:34:22:983 | [430:0x23f5310]   666594 ms: Mark-sweep 4089.3 (4262.1) -> 4089.3 (4261.1) MB, 3898.4 / 0.0 ms  allocation failure GC in old space requested
Aug 22 2019 01:34:22:983 | [430:0x23f5310]   671097 ms: Mark-sweep 4089.3 (4261.1) -> 4089.3 (4225.6) MB, 4502.8 / 0.0 ms  last resort GC in old space requested
Aug 22 2019 01:34:22:983 | [430:0x23f5310]   674990 ms: Mark-sweep 4089.3 (4225.6) -> 4089.3 (4223.1) MB, 3892.4 / 0.0 ms  last resort GC in old space requested
Aug 22 2019 01:34:22:983 | <--- JS stacktrace --->
Aug 22 2019 01:34:22:983 | ==== JS stack trace =========================================
Aug 22 2019 01:34:22:983 | Security context: 0x70e9f6257c1 <JSObject>
Aug 22 2019 01:34:22:983 | 1: toString [buffer.js:611] [bytecode=0x2833662c6061 offset=31](this=0xce2ca70dbc1 <Uint8Array map = 0x6cc06836709>,encoding=0x2fb750b822d1 <undefined>,start=0x2fb750b822d1 <undefined>,end=0x2fb750b822d1 <undefined>)
Aug 22 2019 01:34:22:983 | 2: arguments adaptor frame: 0->3
Aug 22 2019 01:34:22:983 | 3: readFile [/tmp/b0cc21aa63cece4e/.build-utils/.builder/node_modules/@now/next/dist/index.js:9555] [bytecode=0x1814135ff3e1 offset=53](t...
Aug 22 2019 01:34:22:983 | FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
Aug 22 2019 01:34:22:983 | 1:
Aug 22 2019 01:34:22:984 | node::Abort() [/node8/bin/node]
Aug 22 2019 01:34:22:984 | 2:
Aug 22 2019 01:34:22:986 | 0x11e73ec [/node8/bin/node]
Aug 22 2019 01:34:22:986 | 3:
Aug 22 2019 01:34:22:986 | v8::Utils::ReportOOMFailure(char const*, bool) [/node8/bin/node]
Aug 22 2019 01:34:22:986 | 4: v8::internal::V8::FatalProcessOutOfMemory(char const*, bool) [/node8/bin/node]
Aug 22 2019 01:34:22:986 | 5: v8::internal::Factory::NewRawTwoByteString(int, v8::internal::PretenureFlag) [/node8/bin/node]
Aug 22 2019 01:34:22:986 | 6:
Aug 22 2019 01:34:22:986 | v8::internal::Factory::NewStringFromUtf8(v8::internal::Vector<char const>, v8::internal::PretenureFlag) [/node8/bin/node]
Aug 22 2019 01:34:22:986 | 7:
Aug 22 2019 01:34:22:987 | v8::String::NewFromUtf8(v8::Isolate*, char const*, v8::NewStringType, int) [/node8/bin/node]
Aug 22 2019 01:34:22:987 | 8:
Aug 22 2019 01:34:22:987 | node::StringBytes::Encode(v8::Isolate*, char const*, unsigned long, node::encoding, v8::Local<v8::Value>*) [/node8/bin/node]
Aug 22 2019 01:34:22:987 | 9:
Aug 22 2019 01:34:22:988 | 0x12070d6 [/node8/bin/node]
Aug 22 2019 01:34:22:988 | 10:
Aug 22 2019 01:34:22:988 | v8::internal::FunctionCallbackArguments::Call(void (*)(v8::FunctionCallbackInfo<v8::Value> const&)) [/node8/bin/node]
Aug 22 2019 01:34:22:988 | 11:
Aug 22 2019 01:34:22:989 | 0xb79dac [/node8/bin/node]
Aug 22 2019 01:34:22:989 | 12:
Aug 22 2019 01:34:22:989 | v8::internal::Builtin_HandleApiCall(int, v8::internal::Object**, v8::internal::Isolate*) [/node8/bin/node]
Aug 22 2019 01:34:22:989 | 13: 0x47a70c842fd
Aug 22 2019 01:35:32:549 | done

Here's my webpack config:

const loadConfig = require('./loadConfig');

const reNodeModules = /node_modules/;
const reScript = /\.(js|jsx|mjs)$/;
const reImage = /\.(bmp|gif|jpg|jpeg|png|svg)$/;
const reGraphql = /\.graphql?$/;
const reStyle = /\.(css|less|styl|scss|sass|sss)$/;

module.exports = (nextConfig = {}) => {
  return {
    ...nextConfig,
    webpack(config, options) {
      const { webpack, isServer, dev } = options;

      const staticAssetName = dev ? '[path][name].[ext]?[hash:8]' : '[name]-[hash:8].[ext]';
      const publicPath = '/_next/static/';
      const outputPath = `${isServer ? '../' : ''}static/`;

      // eslint-disable-next-line no-param-reassign
      config.resolve = {
        ...config.resolve,
        modules: [...config.resolve.modules, './src'],
      };

      config.module.rules.push(
        {
          test: reImage,
          exclude: reNodeModules,
          oneOf: [
            // Inline lightweight into CSS
            {
              issuer: reStyle,
              oneOf: [
                // Inline lightweight SVGs as UTF-8 encoded DataUrl string
                {
                  test: /\.svg$/,
                  loader: 'svg-url-loader',
                  options: {
                    name: staticAssetName,
                    limit: 4096, // 4kb
                    publicPath,
                    outputPath,
                  },
                },

                // Inline lightweight as Base64 encoded DataUrl string
                {
                  loader: 'url-loader',
                  options: {
                    name: staticAssetName,
                    limit: 4096, // 4kb
                    publicPath,
                    outputPath,
                  },
                },
              ],
            },

            // Or return public URL to image resource
            {
              loader: 'file-loader',
              options: {
                name: staticAssetName,
                publicPath,
                outputPath,
              },
            },
          ],
        }, // Rules for GraphQL
        {
          test: reGraphql,
          exclude: reNodeModules,
          use: [
            {
              loader: 'webpack-graphql-loader',
              options: {
                removeUnusedFragments: true,
                output: 'document',
              },
            },
          ],
        },
        {
          exclude: [reNodeModules, reScript, reImage, reGraphql, /\.json$/, /\.txt$/, /\.md$/],
          loader: 'file-loader',
          options: {
            name: staticAssetName,
            publicPath,
            outputPath,
          },
        },
      );

      const appConfig = loadConfig();
      if (isServer && dev) {
        console.info(appConfig);
      }
      config.plugins.push(
        new webpack.DefinePlugin({
          __DEV__: dev,
          __SERVER__: isServer,
          __BROWSER__: !isServer,
          __CONFIG__: JSON.stringify(appConfig),
        }),
      );

      if (typeof nextConfig.webpack === 'function') {
        return nextConfig.webpack(config, options);
      }

      return config;
    },
  };
};

@timneutkens I'm running out of memory using Next.js 9 as well. It could be because of the number of components we are compiling. You mentioned you needed a full repro of it. You can take a look at my branch.
https://github.com/stramel/styled-icons/tree/ms/add-material-variants

Here is the failing build: https://travis-ci.org/jacobwgillespie/styled-icons/builds/582987078

Travis has NODE_OPTIONS=--max-old-space-size=4096 set

@timneutkens could please reopen the issue now that you have a repo?

I'm facing the same problem with [email protected].

I'm guessing these application(s) have simply hit their size bounds to start running out of memory. You'll need to run your build with more via NODE_OPTIONS=--max-old-space-size=4096.

Alternatively, you can enable our new chunking feature:

// next.config.js
module.exports = {
  experimental: { granularChunks: true }
}

Thanks @Timer, I will give the granularChunks feature a try.

Also, just to note, I had tried 8192 for the value on my local machine and it still failed. I'm a bit scared to imagine how much memory I would need to actually get it to build.

I had a look to some old issue and I noticed that sometimes, when there was a new major release, some people faced this memory issue. I wonder, do you do some memory test on some big project?

This new major release is hitting the node memory cap. What's the cause of this big amount memory that wasn't there before?

@Timer I tried using the granularChunks feature and still ran into the same issue. Even locally with 8192 set.

This has the granular chunks config feature set https://github.com/stramel/styled-icons/tree/ms/granular-chunks

Switched to pulling in components dynamically, https://github.com/stramel/styled-icons/tree/ms/dynamic-import-granular-chunks

This issue happens for one of our repos when we change the build to perform minification, which is disabled by default now.

Update: I determined that in our codebase the issue was using the withSourceMaps plugin:

"@zeit/next-source-maps": "^0.0.4-canary.1"

This makes sense since we have it set to hidden-source-map which is very slow. Though, I don't know why it's exponentially slower than NextJS 8.

We've also noticed massive performance issues after upgrading to v9... I'm using a 2015 macbook pro, it's never lagged before and I've run some pretty heavy programs on it, but now every time i run my next app locally it completely lags out and everything massively slows down.

I usually have to restart the app every 10 minutes or so, today was the first day i tried to persevere and work through it, and after a couple of hours of running in dev move i got that same JavaScript heap out of memory that people have reported from running next build. There must be a memory leak in here somewhere

I think so too. A colleague of mine has a more recent MacBook and since we upgraded to next 9, the dev server has become slower to recompile. Sometimes it takes up do 20 secs.

I'm getting same issue, even tried set NODE_OPTIONS=16384 on my 32GB physic memory MacBook Pro but no effect.

Logs are listed:

==== JS stack trace =========================================

    0: ExitFrame [pc: 0x335bafb5be3d]
Security context: 0x0fe28be1e6e9 <JSObject>
    1: createPrinter [0xfe25fe2c0b9] [/Users/my-name/my-project/node_modules/typescript/lib/typescript.js:~86713] [pc=0x335bb12e86f3](this=0x0fe280c03329 <Object map = 0xfe2df152cc9>,printerOptions=0x0fe2f39e8ae1 <Object map = 0xfe20ac205a9>,handlers=0x0fe28e1026f1 <undefined>)
    2: arguments adaptor frame: 1->2
    3: reportImplicitAny(aka reportImpli...

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 0x10003d035 node::Abort() [/usr/local/opt/nvm/versions/node/v10.16.3/bin/node]
 2: 0x10003d23f node::OnFatalError(char const*, char const*) [/usr/local/opt/nvm/versions/node/v10.16.3/bin/node]
 3: 0x1001b8e15 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/usr/local/opt/nvm/versions/node/v10.16.3/bin/node]
 4: 0x100586d72 v8::internal::Heap::FatalProcessOutOfMemory(char const*) [/usr/local/opt/nvm/versions/node/v10.16.3/bin/node]
 5: 0x100589845 v8::internal::Heap::CheckIneffectiveMarkCompact(unsigned long, double) [/usr/local/opt/nvm/versions/node/v10.16.3/bin/node]
 6: 0x1005856ef v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [/usr/local/opt/nvm/versions/node/v10.16.3/bin/node]
 7: 0x1005838c4 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/usr/local/opt/nvm/versions/node/v10.16.3/bin/node]
 8: 0x10059015c v8::internal::Heap::AllocateRawWithLigthRetry(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [/usr/local/opt/nvm/versions/node/v10.16.3/bin/node]
 9: 0x1005901df v8::internal::Heap::AllocateRawWithRetryOrFail(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [/usr/local/opt/nvm/versions/node/v10.16.3/bin/node]
10: 0x10055fb24 v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationSpace) [/usr/local/opt/nvm/versions/node/v10.16.3/bin/node]
11: 0x1007e7e04 v8::internal::Runtime_AllocateInNewSpace(int, v8::internal::Object**, v8::internal::Isolate*) [/usr/local/opt/nvm/versions/node/v10.16.3/bin/node]
12: 0x335bafb5be3d
13: 0x335bb12e86f3
14: 0x335bafb0a5c3

@timneutkens please reopen this issue, or open a new one. This memory leak as well as some weird infinite HMR requests is making our app unusable in development mode and eating up a huge amount of our time.

Adding another witness.
I inherited an app with Next version 4.2.3.

• Updated it to Next version 9.1.3
• Updated all other packages version in package.json;
• Deleted the node_modules folder and package.lock.json
• ran npm install

When I did a local serve of the project it failed with the following error:
FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
The failure usually happened within less than ten minutes of starting the app and could be hastened by triggering more navigation in the app.

I have reverted to version 8.1.0 and cannot reproduce the same failure--even with more earnest navigation (and thus page-builds).

Yep, we're seeing this too...

Time to re-open I think @timneutkens

I'm facing this issue too on [email protected] with react-router custom server since yesterday since I started to import bootstrap.min.css on my development mode.

both when I import directly the bootstrap.min.css with require/import via js or @import via css/scss. my nodejs memory used been increased after few complies while developing.

but when I import the bootstrap from cdn, via in with next/head, the memory seems to fine even after many complies in long developing time.

<Head>
<meta key="viewport" name="viewport" content="initial-scale=1.0, width=device-width" />
<link key="bootstrapcdn" rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/css/bootstrap.min.css" ...  />
...
</Head>

so I think the problem was on the css minification in next-css. because when I downgrade my project to 8.1.0, I got this minification issue. https://github.com/zeit/next-plugins/issues/541. so I tried this workaround (https://github.com/zeit/next-plugins/issues/392#issuecomment-475845330) . and not yet getting the memory issue again.

// next.config.js
const withCSS = require('@zeit/next-css');

function HACK_removeMinimizeOptionFromCssLoaders(config) {
  console.warn(
    'HACK: Removing 'minimize' option from 'css-loader' entries in Webpack config',
  );
  config.module.rules.forEach(rule => {
    if (Array.isArray(rule.use)) {
      rule.use.forEach(u => {
        if (u.loader === 'css-loader' && u.options) {
          delete u.options.minimize;
        }
      });
    }
  });
}

module.exports = withCSS({
  webpack(config) {
    HACK_removeMinimizeOptionFromCssLoaders(config);
    return config;
  },
});

I'm having that same issue after upgrading to Next 9.1.3. I'm using next-css too, maybe that is indeed what's crashing it?

Not entirely sure if this will be the same for everyone, but make sure to check that any resource you are requesting can actually be found. I had an image that my app couldn't find and it kept looking for it until it gave me the heap error. I removed the mention of that image and it hasn't given me the error again.

I also managed to fix this, @lloan comment helped to debug the issue.

In my case, I was referencing /public/manifest.json as a meta tag in <head/>, however that resource was not present in my project and this was causing the memory leak.

I had this code, which the icon.png doesn't exist

<Head>
  <link rel="icon" href="/static/icon.png" type="image/png" />
</Head>

By fixing the import of the favicon I no longer get the memory leak error

<Head>
  <link rel="icon" href="/icon.png" type="image/png" />
</Head>

As mentioned https://github.com/zeit/now/issues/3307 I believe something's up with static/public folder.

I had this problem too. As bukinoshita mentioned it, I looked into the static folder. I removed a folder of 674 json files (for testing purposes) out of the public/static/ folder. I did not had the problem since.

This issue happens for one of our repos when we change the build to perform minification, which is disabled by default now.

Update: I determined that in our codebase the issue was using the withSourceMaps plugin:

"@zeit/next-source-maps": "^0.0.4-canary.1"

This makes sense since we have it set to hidden-source-map which is very slow. Though, I don't know why it's exponentially slower than NextJS 8.

I started having this issue also after I upgraded to "@zeit/next-source-maps": "^0.0.4-canary.1". Any solution or I'll have to get rid of the source maps?

@focux I had to disable source maps at all. After that, the usage of memory dropped substantially

Have same problem here as well. It seems to crash when the file size in build are too big. For example, I imported something from Typescript and the file size in build went up to 2.41 mb. Then my CI with 2GB ram started to crash. After I removed the Typescript import the file size went down to 100kb and it worked again.

Nextjs 9 has been very slow in CI from start. It takes very long to build and I dont have any special needs... just react stuff, material ui, some packages here and there. I have CI:s in same cluster with node/express, some dotnet core, php etc all these has 1GB memory in CI and builds pretty fast. I dont know more than my feeling about the build process has some issue maybe?

Same problem here. Mac OS / Github Actions. No actions mentioned here helps, can't find any files that are linked but not existent.

However, project builds (and is in production) in Zeit Now.

Would love to help if knew how.

Same problem here (MacOS). What I've found is:

• Starts happening with Next 9.1.5 and 9.1.6. Downgrading to 9.1.4 makes the error dissapear.
• I have my own _ckeditor_ build inside the project, and its size is 606KB. If I remove it the problem disappears.

Let me know if I can help. Here you have the error log...

<--- Last few GCs --->

[83442:0x102804000]   123060 ms: Scavenge 1371.3 (1422.4) -> 1370.7 (1422.9) MB, 8.3 / 0.0 ms  (average mu = 0.120, current mu = 0.058) allocation failure 
[83442:0x102804000]   123066 ms: Scavenge 1371.7 (1422.9) -> 1370.9 (1423.9) MB, 4.1 / 0.0 ms  (average mu = 0.120, current mu = 0.058) allocation failure 
[83442:0x102804000]   123071 ms: Scavenge 1371.7 (1423.9) -> 1371.0 (1424.4) MB, 3.9 / 0.0 ms  (average mu = 0.120, current mu = 0.058) allocation failure 


<--- JS stacktrace --->

==== JS stack trace =========================================

    0: ExitFrame [pc: 0x3b944125be3d]
Security context: 0x164494d1e6e9 <JSObject>
    1: SourceMapConsumer_allGeneratedPositionsFor [0x16448b97d331] [/Users/alberto.iglesias/Coding/iteisa/projects/ceoe-gis/node_modules/@babel/core/node_modules/source-map/lib/source-map-consumer.js:~178] [pc=0x3b944240968c](this=0x1644193fb679 <BasicSourceMapConsumer map = 0x16448ea8a239>,aArgs=0x16447d082249 <Object map = 0x16448ea98939>)
    2: /* anonym...

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 0x10003d035 node::Abort() [/Users/alberto.iglesias/.nvm/versions/node/v10.16.3/bin/node]
 2: 0x10003d23f node::OnFatalError(char const*, char const*) [/Users/alberto.iglesias/.nvm/versions/node/v10.16.3/bin/node]
 3: 0x1001b8e15 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/Users/alberto.iglesias/.nvm/versions/node/v10.16.3/bin/node]
 4: 0x100586d72 v8::internal::Heap::FatalProcessOutOfMemory(char const*) [/Users/alberto.iglesias/.nvm/versions/node/v10.16.3/bin/node]
 5: 0x100589845 v8::internal::Heap::CheckIneffectiveMarkCompact(unsigned long, double) [/Users/alberto.iglesias/.nvm/versions/node/v10.16.3/bin/node]
 6: 0x1005856ef v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [/Users/alberto.iglesias/.nvm/versions/node/v10.16.3/bin/node]
 7: 0x1005838c4 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/Users/alberto.iglesias/.nvm/versions/node/v10.16.3/bin/node]
 8: 0x10059015c v8::internal::Heap::AllocateRawWithLigthRetry(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [/Users/alberto.iglesias/.nvm/versions/node/v10.16.3/bin/node]
 9: 0x1005901df v8::internal::Heap::AllocateRawWithRetryOrFail(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [/Users/alberto.iglesias/.nvm/versions/node/v10.16.3/bin/node]
10: 0x10055fb24 v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationSpace) [/Users/alberto.iglesias/.nvm/versions/node/v10.16.3/bin/node]
11: 0x1007e7e04 v8::internal::Runtime_AllocateInNewSpace(int, v8::internal::Object**, v8::internal::Isolate*) [/Users/alberto.iglesias/.nvm/versions/node/v10.16.3/bin/node]
12: 0x3b944125be3d 
13: 0x3b944240968c 
Abort trap: 6

SourceMapConsumer_allGeneratedPositionsFor I think this is the culprit. In dev mode there's a generation of source maps. I think that overtime, this source map plugin retain too much memory.

I still experience same problem even if I turn off source map generation

Сергей.

On December 24, 2019 at 10:01 GMT, Emanuele notifications@github.com wrote:

SourceMapConsumer_allGeneratedPositionsFor I think this is the culprit. In dev mode there's a generation of source maps. I think that overtime, these source map plugin retain too much memory.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.

Keep in mind that posting "I still experience this" won't solve the issue. Provide a full reproduction for people to look into, otherwise your comment is the same as doing a 👍 on the initial issue but pinging everyone in the issue for no reason.

Always make sure your comments are actionable or useful. Eg like ematipico sharing things based on investigating the issue is useful. Saying "I still have this issue" is not useful.

Is there any workaround? My CI/CD Pipeline fails on 1GB of RAM.

@timneutkens repro steps are as mentioned in this closed issue:

https://github.com/zeit/next.js/issues/9442#issuecomment-554839437

@Vista1nik workaround that worked for me was to recreate the deprecated static directory.

The related now issue:

https://github.com/zeit/now/issues/3307

Just to add to the discussion in case it helps anyone.
I was experiencing an out of memory and then I found out what was the issue in my case:

In the following code snippet, if the const Icon happens to be undefined the code just enters in an infinite loop checking if the component is valid.

const iconMapping = {
  "flash-outline": FlashOutline,
};

export const Icon = ({ name }) => {
  const Icon = iconMapping[name];

  return <Icon />;
}

If I add a check if const Icon is not defined, I get rid of the out of memory issue.

...
  const Icon = iconMapping[name];

  if (!Icon) return null;
  return <Icon />;
}

Same thing happened to me, then I realized was a typo that caused it:

const Button = ({ children }) => {
  // BUG: the button should be lower case (the HTML input)
  //      instead of CamelCase (an undefined component)
  return <Button>{children}</Button>
}

Please try upgrading to the latest version of Next.js, we did a bunch of optimizations to memory usage recently.

@timneutkens, I have the latest version (9.3.5). I created the project this morning and faced that error some minutes later.

Had similar issue on CricleCI while building the app with source maps using next-source-maps

NODE_OPTIONS="--max_old_space_size=4096" helped locally but on CircleCI you also need to increase resource class https://circleci.com/docs/2.0/configuration-reference/#resource_class to large at least to make make it work properly.

I started getting this error after updating to next 9.3.6 today:

<--- Last few GCs --->

[66325:0x108008000]    17639 ms: Mark-sweep 1936.2 (2071.4) -> 1923.6 (2073.4) MB, 283.4 / 0.0 ms  (average mu = 0.157, current mu = 0.048) allocation failure scavenge might not succeed
[66325:0x108008000]    17937 ms: Mark-sweep 1938.1 (2073.4) -> 1925.4 (2075.4) MB, 285.8 / 0.0 ms  (average mu = 0.108, current mu = 0.042) allocation failure scavenge might not succeed


<--- JS stacktrace --->

==== JS stack trace =========================================

Security context: 0x0fb9ac667d09 <JSObject>
    0: builtin exit frame: stringify(this=0x0fb9ac6598a9 <Object map = 0xfb921b01449>,0x0fb958e804d1 <undefined>,0x0fb958e804d1 <undefined>,0x0fb910180ec1 <Object map = 0xfb9d8491399>,0x0fb9ac6598a9 <Object map = 0xfb921b01449>)

    1: arguments adaptor frame: 1->3
    2: callAsync [0xfb9320a6cf9] [0x0fb958e804d1 <undefined>:~1] [pc=0x1aa09fe84627](this=0x0fb9320a6909 <Hook map = 0xfb9d8495179>...

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
...

Fixed it by modifiying paths in tsconfig.json as suggested in #12280

Probably different cause

The same issue is present here after upgrading from 9.0.5 to 9.3.6.

Creating an optimized production build ..
<--- Last few GCs --->

[1600:0000020DB9FFEBE0]    26245 ms: Mark-sweep 1958.0 (2080.3) -> 1945.0 (2081.5) MB, 266.4 / 0.0 ms  (average mu = 0.179, current mu = 0.077) allocation failure scavenge might not succeed
[1600:0000020DB9FFEBE0]    26530 ms: Mark-sweep 1959.9 (2082.0) -> 1947.2 (2083.8) MB, 265.9 / 0.0 ms  (average mu = 0.127, current mu = 0.068) allocation failure scavenge might not succeed


<--- JS stacktrace --->

==== JS stack trace =========================================

    0: ExitFrame [pc: 00007FF77B4D4DDD]
Security context: 0x00e7d00c08d1 <JSObject>
    1: /* anonymous */(aka /* anonymous */) [000002BB3E5CAA29] [C:\Users\...\node_modules\enhanced-resolve\lib\UnsafeCachePlugin.js:~27] [pc=00000147695447FC](this=0x00d9404004b1 <undefined>,0x001a9e083681 <Object map = 000003D51551D3A9>,0x001a9e0838d9 <Object map = 000003D515521AE9>,0x001a9e083979 ...

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 00007FF77A8D363F napi_wrap+128063
 2: 00007FF77A872836 v8::base::CPU::has_sse+35142
 3: 00007FF77A8734F6 v8::base::CPU::has_sse+38406
 4: 00007FF77B089F4E v8::Isolate::ReportExternalAllocationLimitReached+94
 5: 00007FF77B072021 v8::SharedArrayBuffer::Externalize+833
 6: 00007FF77AF3E57C v8::internal::Heap::EphemeronKeyWriteBarrierFromCode+1436
 7: 00007FF77AF497D0 v8::internal::Heap::ProtectUnprotectedMemoryChunks+1312
 8: 00007FF77AF462F4 v8::internal::Heap::PageFlagsAreConsistent+3204
 9: 00007FF77AF3BB13 v8::internal::Heap::CollectGarbage+1283
10: 00007FF77AF3A184 v8::internal::Heap::AddRetainedMap+2452
11: 00007FF77AF5C734 v8::internal::Factory::NewInternalizedStringImpl+132
12: 00007FF77AD9C7FD v8::internal::DescriptorArray::Allocate+4941
13: 00007FF77ADAD0C5 v8::internal::StringTable::LookupString+373
14: 00007FF77AAAF356 v8::internal::Factory::InternalizeName+54
15: 00007FF77ACAB0BE v8::internal::Runtime::GetObjectProperty+9662
16: 00007FF77B4D4DDD v8::internal::SetupIsolateDelegate::SetupHeap+546637
17: 00000147695447FC

Any idea?

@szaza can you try next@canary, the most likely case is that you have the issue described here: https://github.com/zeit/next.js/issues/12280

Ok, after deleting the node_modules and reinstalling dependencies it seems that it works with the canary version, however I've got now another error: Cannot find module 'next-server/dist/server/next-server'.. Does it seems familiar to you?

Oh I got it, it has been moved to import Server from "next/dist/next-server/server/next-server";.
Now it works fine. Thanks for your help!

@szaza how did you end up importing that module in your project? It's an internal module? I guess you meant to import 'next' instead?

I'm working on a large project written in TypeScript. There is a passport authentication middleware configured, which redirects the unauthorized users back to the login page. It is implemented the following way:

import Server from "next-server/dist/server/next-server";
...
export const initPassport = (
    server: Express,
    app: Server,
    authStrategies: string[]
) => {
...
return app.render(req, res, AuthRoutes.LOGIN_PAGE);
...
}

After updating next version from 9.0.5 to 9.3.7-canary.0, Server type couldn't be imported anymore from next-server/dist/..., but from from the path mentioned above.

I had same error when I upgraded all libraries in my package.json. Currently I am using NextJS 9.2.2 with @zeit/next-css without any issue. Seems like some version of libraries raises out of memory issue or they are somehow conflicting with NextJS .

My current package configuration is --

{
"dependencies": {
    "@zeit/next-css": "^1.0.1",
    "axios": "^0.19.2",
    "body-parser": "^1.19.0",
    "compression": "^1.7.4",
    "cookie-parser": "^1.4.4",
    "cookie-session": "^1.4.0",
    "express": "^4.17.1",
    "helmet": "^3.21.3",
    "json-server": "^0.16.1",
    "morgan": "^1.9.1",
    "next": "^9.2.2",
    "passport": "^0.4.1",
    "passport-local": "^1.0.0",
    "passport-strategy": "^1.0.0",
    "prop-types": "^15.7.2",
    "react": "^16.13.0",
    "react-dom": "^16.13.0",
    "react-mathjax2": "0.0.2",
    "shaka-player": "^2.5.10",
    "styled-components": "^5.0.1"
  },
  "devDependencies": {
    "@babel/cli": "^7.8.4",
    "@babel/core": "^7.9.0",
    "@babel/preset-env": "^7.8.6",
    "@babel/preset-react": "^7.8.3",
    "babel-jest": "^25.1.0",
    "babel-plugin-module-resolver": "^4.0.0",
    "babel-plugin-styled-components": "^1.10.7",
    "enzyme": "^3.11.0",
    "enzyme-adapter-react-16": "^1.15.2",
    "jest": "^25.1.0",
    "react-test-renderer": "^16.13.0"
  }
}

I narrowed down my particular issue to the usage of library https://github.com/google/schema-dts. When type definitions from this library were being used in my Next app, the build never completed, Macbook fans go to full power and eventually spat out some OOM report json file at the root of the project.

I debugged the issue by removing all but one page from pages/ and removing code until the project built and then gradually putting code back in.

Maybe this helps someone who comes across this thread 🤷‍♂️

Had similar issue on CricleCI while building the app with source maps using next-source-maps

NODE_OPTIONS="--max_old_space_size=4096" helped locally but on CircleCI you also need to increase resource class https://circleci.com/docs/2.0/configuration-reference/#resource_class to large at least to make make it work properly.

This is the only thing that worked for us 👍

On a fairly large Next.js app (v9.3.6) a number of us were running into out of heap memory issues on app startup (dev mode) for which setting NODE_OPTIONS="--max_old_space_size=4096" helped for Node 10, or alternately, on Node 12 and beyond, this is taken care of for you with this commit and another that takes into account the amount of memory allocated to a container (Linux only afaik).

Just to add to the discussion in case it helps anyone.
I was experiencing an out of memory and then I found out what was the issue in my case:

In the following code snippet, if the const Icon happens to be undefined the code just enters in an infinite loop checking if the component is valid.

const iconMapping = {
  "flash-outline": FlashOutline,
};

export const Icon = ({ name }) => {
  const Icon = iconMapping[name];

  return <Icon />;
}

If I add a check if const Icon is not defined, I get rid of the out of memory issue.

...
  const Icon = iconMapping[name];

  if (!Icon) return null;
  return <Icon />;
}

How did you figure this out that this is the piece of code caused this issue?

Interesting enough, looking at this code again I actually see another
problem. Icon is a component and inside of Icon I was referencing the Icon
itself.

The way I figure it out was mostly by isolating component by component and
try to reproduce the issue till I find out which component was provoking
that.

On Thu, 21 May 2020 at 18:20, Vivek_Neel notifications@github.com wrote:

Just to add to the discussion in case it helps anyone.
I was experiencing an out of memory and then I found out what was the
issue in my case:

In the following code snippet, if the const Icon happens to be undefined
the code just enters in an infinite loop checking if the component is valid.

const iconMapping = {
"flash-outline": FlashOutline,
};
export const Icon = ({ name }) => {
const Icon = iconMapping[name];

return ;
}

If I add a check if const Icon is not defined, I get rid of the out of
memory issue.

...
const Icon = iconMapping[name];

if (!Icon) return null;
return ;
}

How did you figure this out that this is the piece of code caused this
issue?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/zeit/next.js/issues/7929#issuecomment-632187103, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ABA2CL7ZJQY5YPYJVCJMCODRSVIE7ANCNFSM4ICM4RAA
.

>

Sent from my phone

As far as I understood, Next.js (since v9.0.0) is not able to optimize the memory of large web applications. Our build process hits the memory limit when it starts to compile the server side part of the project.

During development mode, the local server is fine initially but after some time the allocated memory blows up and the memory heap error shows up.

Could someone from the core team please acknowledge this issue and help us to triage the problem?

Me and my team, even with powerful laptops, are not able to build locally the application sometimes. This issue is almost 1 year old but there hasn't been a clear update around the issue. Personally, the only workaround that I can think of is to split the application in two sub Next.js projects because I am concerned that one day we won't even be able to build the application even on the CI (and we already using powerful VMs for doing it).

I am so sorry to be the bad guy here, I am just seeking for help.

EDIT: we updated to Next.js 9.3.3 but there haven't been improvements

Could someone from the core team please acknowledge this issue and help us to triage the problem?

I've asked you multiple times on this thread to provide a full reproduction or provide your application. We can't analyze anything in your particular application to track down the issue in your application.
We've changed sourcemap generation in 9.4 btw so you should definitely upgrade to the latest version.

FWIW cases like https://github.com/zeit/next.js/issues/7929#issuecomment-618297553 are infinite loops created inside of your application and we can't detect these very well (as they end up going through React rendering).

As far as I understood, Next.js (since v9.0.0) is not able to optimize the memory of large web applications. Our build process hits the memory limit when it starts to compile the server side part of the project.

Given that you did not provide a reproduction I can only reference our own applications.

We run millions of requests on Next.js and the applications that we run have 300+ pages. We've had no memory issues reported from our teams and they work on many pages throughout their day.

Note that this is not me denying there could be an issue, I'm just saying it's impossible to track down if there is an issue if you're not going to provide a clear reproduction or application that we can profile.
Also note that I'm not even asking for that to be paid consulting, we'll have a look at the application for free.

I've asked you multiple times on this thread to provide a full reproduction or provide your application. We can't analyze anything in your particular application to track down the issue in your application.

Other people have provided repositories here since I opened the issue. That's why the issue was reopened and that's why it doesn't have the label that says it requires a repository to reproduce the issue.

• https://github.com/zeit/next.js/issues/7929#issuecomment-529756317

Ever since it was left opened

I can't provide a repository because the web application belongs to my client and the source code is closed.

We've changed sourcemap generation in 9.4 btw so you should definitely upgrade to the latest version.

Is this feature opt-in/opt-out? I removed the generation of source maps (it was done via plugin) after I opened the issue (so long time ago) but it didn't help much.

If you think that this issue is not valid, please close it. The repo was shared long time ago and it might not be valid anymore.

I can help with the triaging but I'd need guidance.

▲  styled-icons (master) ✗ yarn build:ci
yarn run v1.22.4
$ lerna run build
lerna notice cli v3.21.0
lerna info Executing command in 25 packages: "yarn run build"
lerna info run Ran npm script 'build' in '@styled-icons/styled-icon' in 6.6s:
$ tsc --project tsconfig.esm.json && mv dist/index.js dist/index.esm.js && tsc --project tsconfig.json
lerna ERR! yarn run build exited 1 in '@styled-icons/boxicons-logos'
lerna ERR! yarn run build stdout:
$ build-pack
Reading icon packs...
Error reading icons from pack
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

lerna ERR! yarn run build stderr:
error Command failed with exit code 1.

lerna ERR! yarn run build exited 1 in '@styled-icons/boxicons-logos'
lerna WARN complete Waiting for 4 child processes to exit. CTRL-C to exit immediately.
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

The reproduction can't be executed, hence why I asked every single person that reported here to also provide a reproduction to avoid cases like this. Also the potential for these issues to be 100% the same is quite low.

Is this feature opt-in/opt-out? I removed the generation of source maps (it was done via plugin) after I opened the issue (so long time ago) but it didn't help much.

Sourcemaps are always enabled in development, we switched to eval source maps though.

That's why the issue was reopened and that's why it doesn't have the label that says it requires a repository to reproduce the issue.

I re-opened it because more reports kept coming in and I kept asking for reproductions: https://github.com/zeit/next.js/issues/7929#issuecomment-568760542

There's only 2 reproductions provided in this thread. One is completely unrelated to Next.js (now dev memory consumption) and the other can't be executed/built.

Hence why I'm once again asking for a full reproduction otherwise this will continue to be impossible to investigate.

I can't provide a repository because the web application belongs to my client and the source code is closed.

Feel free to reach out to [email protected] and we can set up a NDA, potentially this does mean we'll have to do consulting for you though given it'll take a significant amount of time to set all this up just to help you with your particular application and you're building the application for a client also.

I'm guessing these application(s) have simply hit their size bounds to start running out of memory. You'll need to run your build with more via NODE_OPTIONS=--max-old-space-size=4096.

Alternatively, you can enable our new chunking feature:

// next.config.js
module.exports = {
  experimental: { granularChunks: true }
}

This didn't solve our issue, FYI.

Anyone knows if this issue occurs in the inbuilt next server start?
ie: Next start rather than NODE_ENV=production node server.js"?

My problem arises after generating the build. On my custom server running "node server.js" it builds up memory until I receive that error and the process restarts which means it looses all the cached routes and stuff so it is really slow for the first user that enters the pages after that as all the SSR is happening.

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
0|profiles |  1: 0xa093f0 node::Abort() [node /home/projects/profiles/server.js]
0|profiles |  2: 0xa097fc node::OnFatalError(char const*, char const*) [node /home/projects/profiles/server.js]
0|profiles |  3: 0xb842ae v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [node /home/projects/profiles/server.js]
0|profiles |  4: 0xb84629 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [node /home/projects/profiles/server.js]
0|profiles |  5: 0xd30fe5  [node /home/projects/profiles/server.js]
0|profiles |  6: 0xd31676 v8::internal::Heap::RecomputeLimits(v8::internal::GarbageCollector) [node /home/projects/profiles/server.js]
0|profiles |  7: 0xd3def5 v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [node /home/projects/profiles/server.js]
0|profiles |  8: 0xd3eda5 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [node /home/projects/profiles/server.js]
0|profiles |  9: 0xd4185c v8::internal::Heap::AllocateRawWithRetryOrFail(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [node /home/projects/profiles/server.js]
0|profiles | 10: 0xd0830b v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationType, v8::internal::AllocationOrigin) [node /home/projects/profiles/server.js]
0|profiles | 11: 0x1049f4e v8::internal::Runtime_AllocateInYoungGeneration(int, unsigned long*, v8::internal::Isolate*) [node /home/projects/profiles/server.js]
0|profiles | 12: 0x13cf019  [node /home/projects/profiles/server.js]

This is my package.json

{
  "name": "profiles",
  "version": "0.1.0",
  "private": true,
  "scripts": {
    "dev": "node server.js",
    "build": "yarn relay && next build",
    "start": "NODE_ENV=production node server.js",
    "relay": "relay-compiler --src ./ --exclude '**/.next/**' '**/node_modules/**' '**/test/**'  '**/__generated__/**' --exclude '**/schema/**' --schema ./var/schema.graphql --artifactDirectory __generated__",
    "relay-get-schema-stage": "graphql get-schema --project sourcr --endpoint stage && yarn run relay",
    "relay-get-schema-prod": "graphql get-schema --project sourcr --endpoint prod && yarn run relay",
    "relay-get-schema-dev": "graphql get-schema --project sourcr --endpoint dev && yarn run relay",
    "pm2": "pm2"
  },
  "dependencies": {
    "@babel/plugin-proposal-class-properties": "^7.10.4",
    "@babel/plugin-proposal-decorators": "^7.10.5",
    "@babel/plugin-proposal-export-default-from": "^7.10.4",
    "@babel/plugin-proposal-optional-chaining": "^7.11.0",
    "@babel/plugin-syntax-dynamic-import": "^7.8.3",
    "@babel/plugin-transform-runtime": "^7.11.0",
    "@fortawesome/fontawesome": "^1.1.8",
    "@fortawesome/fontawesome-free-regular": "^5.0.13",
    "@fortawesome/fontawesome-free-solid": "^5.0.13",
    "@fortawesome/react-fontawesome": "^0.1.11",
    "@sentry/browser": "^5.21.0",
    "@svgr/webpack": "^5.4.0",
    "babel-loader": "^8.1.0",
    "babel-plugin-styled-components": "^1.11.1",
    "babel-plugin-transform-export-extensions": "^6.22.0",
    "bootstrap": "^4.5.2",
    "classnames": "^2.2.6",
    "file-loader": "^6.0.0",
    "formsy-react": "^1.1.5",
    "graphql": "^15.3.0",
    "jwt-decode": "^2.2.0",
    "mobx": "^5.15.5",
    "moment": "^2.28.0",
    "next": "9.5.1",
    "path": "^0.12.7",
    "pm2": "^4.5.0",
    "query-string": "^6.13.1",
    "react": "16.13.1",
    "react-dom": "16.13.1",
    "react-helmet": "^6.1.0",
    "react-player": "^2.6.0",
    "react-relay": "^10.0.1",
    "react-relay-network-modern": "^4.7.4",
    "react-relay-network-modern-ssr": "^1.4.0",
    "react-toastify": "^6.0.8",
    "relay-compiler": "^10.0.1",
    "relay-devtools": "^1.4.0",
    "relay-devtools-core": "^0.0.8",
    "relay-runtime": "^10.0.1",
    "sass": "^1.26.10",
    "sass-resources-loader": "^2.0.3",
    "siema": "^1.5.1",
    "transform-class-properties": "^0.1.0"
  },
  "devDependencies": {
    "babel-plugin-relay": "^10.0.1"
  }
}

For anyone who might be dealing with a runaway next build running out of memory, try deleting your .babelrc or babel.config.js. I have a .babelrc for a separate part of my project not related to Next.js, and it doesn't agree with next build. In my situation, the issue was only happening in Docker. I fixed it by changing my Dockerfile from this

FROM node:12
WORKDIR /app
COPY package.json package-lock.json /app/
ENV NODE_ENV production
RUN npm install
COPY . /app
RUN npm run build
RUN npm run next-build
EXPOSE 8081
CMD ["npm", "start"]

to this

FROM node:12
WORKDIR /app
COPY package.json package-lock.json /app/
ENV NODE_ENV production
RUN npm install
COPY . /app
RUN npm run build
# Let Next.js use its own Babel config
RUN rm .babelrc
RUN npm run next-build
EXPOSE 8081
CMD ["npm", "start"]

For those using shared runners in GitLab CI, those runners will kill your build process with SIGABRT and in turns trigger this error. We switched back to our group runner and it worked.

In case any of you is using next-transpile-modules, my solution was to enable resolveSymlinks-setting (since v4.1.0) like so:

// next.config.js
const withTM = require("next-transpile-modules")([
    "somepackage"
], {
    resolveSymlinks: true
})
module.exports = {
    ...withTM()
}

I first encountered the issue described here when somepackage became "too big" (from 500kb to 700kb), now all of a sudden, all of my memory (also tried with the 8gb option) was not enough to handle this.

I believe that there are some symlink-caused loops which cause memory to get bloated exponentially.