Process out of memory - Webpack

[andrewhathaway]

After a couple of builds running in a Watch, Webpack crashes due to being out of memory.

<--- Last few GCs --->

 9223585 ms: Scavenge 1390.0 (1454.7) -> 1390.0 (1454.7) MB, 9.0 / 0 ms (+ 0.7 ms in 1 steps since last GC) [allocation failure] [incremental marking delaying mark-sweep].
 9224727 ms: Mark-sweep 1390.0 (1454.7) -> 1388.3 (1452.7) MB, 1142.7 / 0 ms (+ 9.8 ms in 89 steps since start of marking, biggest step 2.5 ms) [last resort gc].
 9225694 ms: Mark-sweep 1388.3 (1452.7) -> 1388.8 (1454.7) MB, 966.6 / 0 ms [last resort gc].

<--- JS stacktrace --->

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

Security context: 0x35903c44a49 <JS Object>
    1: walkFunctionDeclaration [<PROJECT_DIR>/node_modules/webpack/lib/Parser.js:~443] [pc=0xa07a14ec8ee] (this=0x59f67991119 <a Parser with map 0x71f2d115d49>,statement=0x3507a80af661 <a Node with map 0x71f2d1157c9>)
    2: walkStatement [<PROJECT_DIR>/node_modules/webpack/lib/Parser.js:~348] [pc=0xa07a06dfc10] (this=0x59f6799111...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - process out of memory
Abort trap: 6

[SpaceK33z]

I'm having this too with webpack-dev-server on Debian; but I haven't had time to debug this further. Do you have a minimal webpack config where you can reproduce this? It could also be an external loader or plugin.

[sokra]

Don't use hashes when watching. i. e. [chunkhash] causes all assets to be stored.

[SimenB]

@sokra In the documentation for css-loader it says to use hash for easier debugging wrt css modules. Does that have the same problem?

You can configure the generated ident with the localIdentName query parameter (default [hash:base64]). Example: css-loader?localIdentName=[path][name]---[local]---[hash:base64:5] for easier debugging.

We've also started to see this problem in dev (out of memory), but our only hash in dev mode is the css one.

EDIT: Of course it uses hash by default, so I'm guessing it's not a problem.

[sokra]

Does that have the same problem?

No. Only filenames.

You can compare it with webpack --watch. If this generates many files in to your output path, the webpack-dev-server generates many files in the memory-fs.

If this is not the issue, you can increase the node.js memory (it defaults to 1.7 GB, which can be too few for big builds).

[SimenB]

I'll test at work on Monday! If the outputted file is of the same name as the old one, then it's overwritten, right?

[sokra]

jup.

You can navigate to http://localhost:8080/webpack-dev-server to see a list of all files in memory.

[SimenB]

Ah, didn't know that! Using a small project I have on my own computer, I notice that all of the hot-update files gets added.

Could they be a problem? Any way of clearing them out after they've been there for x amount of time? If we develop for a few hours there's probably quite a few of them in the end

[sokra]

Could they be a problem?

They could, but they are usually pretty small.

[SpaceK33z]

I think clearing them out like @SimenB said would be a nice option, or maybe there is some way to delete all in-memory files that are no longer in use?

[sokra]

jup. Write a plugin...

[sokra]

But deleting them too early can break stuff...

[deepakmani]

We have the exact same memory leak problem after using webpack -w on MacOS X. Can you please suggest what is a the best way to fix / workaround this issue. The ngOfficeUIFabric seems to deal with a different problem.

Thanks, Deepak

[luchillo17]

Have same issue of @deepakmani in OSX El Capitan, however i'm using Ionic 2 which in it's config doesn't use css-loader, instead it just uses ionic-gulp-sass-build, so ikd if the error happens because of webpack or that gulp plugin, also i'm not using HRM:

const path = require('path')
const PrefetchPlugin = require('webpack/lib/PrefetchPlugin')
const ProvidePlugin = require('webpack/lib/ProvidePlugin')
const DedupePlugin = require('webpack/lib/optimize/DedupePlugin')
const UglifyJsPlugin = require('webpack/lib/optimize/UglifyJsPlugin')
const WebpackNotifierPlugin = require('webpack-notifier')

module.exports = {
  entry: {
    polyfills: './app/polyfills.ts',
    vendor: './app/vendor.ts',
    app: path.resolve('app/app')
  },
  output: {
    path: path.resolve('www/build/js'),
    filename: '[name].bundle.js',
    publicPath: "/",
    chunkFilename: "[id].bundle.js",
    pathinfo: false, // show module paths in the bundle, handy for debugging
  },
  devtool: 'eval',
  module: {
    loaders: [
      {
        test: /\.ts$/,
        loader: 'awesome-typescript',
        query: {
          doTypeCheck: true,
          resolveGlobs: false,
          externals: ['typings/main.d.ts']
        },
        include: path.resolve('app'),
        exclude: /node_modules/
      }
      ,{
        test: /\.js$/,
        include: path.resolve('node_modules/angular2'),
        loader: 'strip-sourcemap'
      }
    ],
    noParse: [
      /es6-shim/,
      /reflect-metadata/,
      /zone\.js(\/|\\)dist(\/|\\)zone/
    ]
  },
  plugins: [
    new PrefetchPlugin('rxjs'),
    new ProvidePlugin({
      Chart: 'chart.js/Chart.min.js'
    }),
    new DedupePlugin()
    // ,new UglifyJsPlugin({
    //    // to debug prod builds uncomment //debug lines and comment //prod lines
    //   // beautify: true,//debug
    //   // mangle: false,//debug
    //   // dead_code: false,//debug
    //   // unused: false,//debug
    //   // deadCode: false,//debug
    //   // compress : { screw_ie8 : true, keep_fnames: true, drop_debugger: false, dead_code: false, unused: false, }, // debug
    //   // comments: true,//debug

    //   beautify: false,//prod
    //   // disable mangling because of a bug in angular2 beta.1, beta.2 and beta.3
    //   // TODO(mastertinner): enable mangling as soon as angular2 beta.4 is out
    //   // mangle: { screw_ie8 : true },//prod
    //   mangle: false,
    //   // dead_code : true,
    //   compress : { 
    //     dead_code : true,
    //     screw_ie8 : true
    //   },//prod
    //   comments: false//prod
    // })
    ,new WebpackNotifierPlugin({
      title: 'tao_app_ionic',
      alwaysNotify: true
      // contentImage: path.join(appDir, 'images/notifier.png')
    })
  ],
  resolve: {
    alias: {
      'angular2': path.resolve('node_modules/angular2')
    },
    extensions: ['', '.js', '.ts']
  }
};

[guruprasanth5]

I am having the same issue, any hack that can fix this for now.

[thunderkid]

Having the same problem running webpack via webpack-stream in gulp. I use gulp.watch to rerun on code changes, which then just runs

    return gulp.src(tsStartFile)
              .pipe(webpackStream(webPackConfig))
              .on('error', logError) 
              .pipe(gulp.dest(outputDir))

I'd have thought this would run webpack from scratch each time, but after 5 or so builds I get the out of memory error and have to rerun my gulp file.

[Pines-Cheng]

Did someone resolved this problem？

[tdsmithATabc]

Another data point here; I have filename hashes disabled and my build isn't terribly large (it uses Angular 2, but few other dependencies), but after about an hour of dev work the watch dies with Abort trap: 6.

I've temporarily increased the memory limit, which gives me a lot more time, but I'd rather not be consuming gigabytes just to run a watch command.

FYI if anyone is curious about upping the memory limit, I did it like so in my package.json (obviously the additional flags are dependent on your needs):

{
  "scripts": {
    "start": "node --max_old_space_size=4096 node_modules/webpack-dev-server/bin/webpack-dev-server.js --inline --progress --port 3000 --open"
  }
}

[mikiest]

Having the same issue as @thunderkid here. Any update?

[rochdev]

Same issue for a very small project

[tdsmithATabc]

For reference, using the flag isn't really helping me anymore and I think it was just a placebo. I don't think it's an actual memory issue because I've monitored system-level memory usage and I have yet to see it pass ~500MB.

I haven't found any way to get node to emit any additional error details beyond the abort trap. It sounds like maybe we should be escalating this with NodeJS team, since having an uninformative but consistent failure message is certainly a bug...

[ha404]

This just happened recently with a large project. It hadn't happened in the past. We did, however, just switch to using Docker.

[doberkofler]

I'm getting the FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory basically after every 5-10 rebuilds in dev mode using --watch. Is there any way to get around this in webpack 1.14.0?

[CyrilWork]

Hello Webpack, after a few weeks of having webpack open and running I also got a memory error with "last resort gc" ... "Allocation failed - JavaScript heap out of memory Exit with" ... "[bg] Exited with code 3"

webpack version 0.6.0

webpack-core@~0.6.0: version "0.6.8" resolved "https://registry.yarnpkg.com/webpack-core/-/webpack-core-0.6.8.tgz#edf9135de00a6a3c26dd0f14b208af0aa4af8d0a" dependencies: source-list-map "~0.1.0" source-map "~0.4.1" webpack-dev-middleware@^1.2.0: version "1.8.4" resolved "https://registry.yarnpkg.com/webpack-dev-middleware/-/webpack-dev-middleware-1.8.4.tgz#e8765c9122887ce9e3abd4cc9c3eb31b61e0948d" dependencies: memory-fs "~0.3.0" mime "^1.3.4" path-is-absolute "^1.0.0" range-parser "^1.0.3" webpack-hot-middleware@^2.8.1: version "2.13.2" resolved "https://registry.yarnpkg.com/webpack-hot-middleware/-/webpack-hot-middleware-2.13.2.tgz#6500b15e6d4f1a9590f8df708183f4d2ac2c3e9e" dependencies: ansi-html "0.0.6" html-entities "^1.2.0" querystring "^0.2.0" strip-ansi "^3.0.0" webpack-isomorphic-tools@^2.2.24: version "2.6.4" resolved "https://registry.yarnpkg.com/webpack-isomorphic-tools/-/webpack-isomorphic-tools-2.6.4.tgz#1bdd03981429dc711ba57549c2a79953cd26e2b0" dependencies: babel-runtime "^6.6.1" colors "^1.1.2" fs-extra "^0.30.0" require-hacker "^2.1.3" sync-request "^3.0.1" uglify-js "^2.7.0" webpack-sources@^0.1.0: version "0.1.3" resolved "https://registry.yarnpkg.com/webpack-sources/-/webpack-sources-0.1.3.tgz#15ce2fb79d0a1da727444ba7c757bf164294f310" dependencies: source-list-map "~0.1.0" source-map "~0.5.3" webpack@^1.12.3: version "1.13.3" resolved "https://registry.yarnpkg.com/webpack/-/webpack-1.13.3.tgz#e79c46fe5a37c5ca70084ba0894c595cdcb42815" dependencies: acorn "^3.0.0" async "^1.3.0" clone "^1.0.2" enhanced-resolve "~0.9.0" interpret "^0.6.4" loader-utils "^0.2.11" memory-fs "~0.3.0" mkdirp "~0.5.0" node-libs-browser "^0.6.0" optimist "~0.6.0" supports-color "^3.1.0" tapable "~0.1.8" uglify-js "~2.7.3" watchpack "^0.2.1" webpack-core "~0.6.0"

[l-astro]

Same issue has just started for me. Has there been any update on this?

[bradennapier]

Also having this issue :( hashes for css-modules are a must for development!

[noah79]

Same problem. Our production builds have recently started failing too. Typescript + React. We've increased memory for our node processes to no avail. Any advice or what version to roll back to?

[RaulTsc]

Same issue here. Running webpack dev server takes up ~3-3.5gb of ram on my machine

[krazyjakee]

Security context: 0x354f7b2a66a1 <JS Object>
    0: builtin exit frame: stringify(this=0x354f7b29a7d1 <a JSON with map 0x8ddf39053d9>,0xd2259a02311 <undefined>,0xd2259a02311 <undefined>,0x225fe8c83c11 <an Object with map 0x1460ed77b201>)

    1: arguments adaptor frame: 1->3
    2: /* anonymous */(aka /* anonymous */) [/Users/x/WebApp/node_modules/webpack/lib/SourceMapDevToolPlugin.js:~112] [pc=0xaf6d181150b](this=0xd2259a0231...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory

[Venryx]

I'm also getting this error, except in Webpack 2: 😞 (with webpack-dev-middleware)

webpack: Compiling...
webpack building...
webpack: wait until bundle finished: /index.html

<--- Last few GCs --->

  107742 ms: Mark-sweep 1363.5 (1415.9) -> 1361.9 (1415.9) MB, 1137.0 / 0.0 ms [allocation failure] [GC in old space requested].
  109016 ms: Mark-sweep 1361.9 (1415.9) -> 1361.9 (1415.9) MB, 1274.0 / 0.0 ms [allocation failure] [GC in old space requested].
  110267 ms: Mark-sweep 1361.9 (1415.9) -> 1366.0 (1404.9) MB, 1251.0 / 0.0 ms [last resort gc].
  111552 ms: Mark-sweep 1366.0 (1404.9) -> 1370.0 (1404.9) MB, 1285.0 / 0.0 ms [last resort gc].

<--- JS stacktrace --->

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

Security context: 00000248DD2CFB61 <JS Object>
    1: set [native collection.js:~252] [pc=000003C901E0A3E4] (this=000002BF0455F139 <a Map with map 0000015D1F80A191>,r=000003CA712E4119 <String[12]: linkParentID>,z=0000009BCCF0CBD9 <a TypeObject with map 000000F54E3505A1>)
    2: getLiteralTypeForText [C:\Root\Apps\@V\DebateMap\Main\node_modules\typescript\lib\typescript.js:~30635] [pc=000003C900E6C15B] (this=00000248DD2E6661 <JS Global Obj...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
[nodemon] app crashed - waiting for file changes before starting...

EDIT

Okay, in my case, the problem is that I had:

FileA.tsx:

import {ButtonProps} from "../../../../Frame/ReactComponents/Button";

Button.tsx:

export type ButtonProps = {enabled?: boolean, [...]} & React.HTMLProps<HTMLDivElement>;

In other words, importing a type definition that depends on React's HTMLProps<HTMLDivElement> type.

Interestingly, I made the same import of the ButtonProps type from a different file, and it doesn't cause the build to fail there.

So perhaps it's a bug, or perhaps it's something else, like the fact that React's types use generics a lot.

Still doesn't fully explain it, though, since it shouldn't just be a memory limit being hit. (I upped the limit using --max_old_space_size=4096, and it didn't change anything -- and the process only ever went up to 1.42gb of usage)

[skytreader]

I'm experiencing the same issue here. From what can I tell, it seems that Webpack is loading up files in the project directory even when they are technically "unreachable" from the dependency graph, starting from the given entry points.

I'm trying to integrate Webpack into an existing project with a large existing Javascript code (written as Typescript). This is where Webpack throws OOM errors.

So as an experiment, I try to make a minimal Webpack test example, as described in this gist. This compiles fine, so far so good.

But, when I copy the src directory of the large project into my minimal example, Webpack then throws OOM errors. Note that I just copied the src directory; none of the files in the given gist example were changed.

FWIW, I ran Webpack with strace and I get traces like

open("/node_modules/@types/zeroclipboard.d.ts", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/node_modules/@types/zeroclipboard/package.json", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/node_modules/@types/zeroclipboard/index.d.ts", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
...
open("/home/node_modules/zeroclipboard.js", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/home/node_modules/zeroclipboard.jsx", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/home/node_modules/zeroclipboard/package.json", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/home/node_modules/zeroclipboard/index.js", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/home/node_modules/zeroclipboard/index.jsx", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

I'm not sure if this is normal behavior or not but it is looking for node_modules way beyond where it is supposed to look.

strace also makes me sure that Webpack is indeed digging into the unreferenced src directory. I get traces like,

open("/home/chad/kode/test/src/DefinitelyTyped/zeroclipboard/node_modules/zeroclipboard.tsx", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/home/chad/kode/test/src/DefinitelyTyped/zeroclipboard/node_modules/zeroclipboard.d.ts", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/home/chad/kode/test/src/DefinitelyTyped/zeroclipboard/node_modules/zeroclipboard/package.json", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/home/chad/kode/test/src/DefinitelyTyped/zeroclipboard/node_modules/zeroclipboard/index.ts", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/home/chad/kode/test/src/DefinitelyTyped/zeroclipboard/node_modules/zeroclipboard/index.tsx", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/home/chad/kode/test/src/DefinitelyTyped/zeroclipboard/node_modules/zeroclipboard/index.d.ts", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/home/chad/kode/test/src/DefinitelyTyped/zeroclipboard/node_modules/@types/zeroclipboard.d.ts", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/home/chad/kode/test/src/DefinitelyTyped/zeroclipboard/node_modules/@types/zeroclipboard/package.json", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/home/chad/kode/test/src/DefinitelyTyped/zeroclipboard/node_modules/@types/zeroclipboard/index.d.ts", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

[Venryx]

Three hours? I think the problem is just that you need more patience.

[Macmee]

+1 same issue here deploying to heroku

[meltingice]

Not sure if there is anyone else here using webpacker, but the problem for me was that in config/webpack/shared.js they changed this:

const extensionGlob = `*{${paths.extensions.join(',')}}*`

to this:

const extensionGlob = `**/*{${settings.extensions.join(',')}}*`

Which explains why it may be traversing down directories and loading files that are never actually used by the dependency graph. Dropping the **/ fixed the out of memory issue for me.

[ertrzyiks]

The problem for me was a memory leak in postcss-loader v1.3.x, no more crashes so far after an upgrade to v.2.0.5

[dcalhoun]

@ertrzyiks thanks for the info. Do you have a link referencing the memory leak (i.e. a Github PR or Issue) or is that something you discovered on your own?

[ertrzyiks]

@dcalhoun it's something I discovered on my own, I couldn't find any commit dedicated to fixing this, a memory leak has been removed as a side effect of recent refactoring I guess

[dcalhoun]

@eirikurn Alright. After looking into it, it looks like postcss-loader#2.0.0 did update to postcss#6.0, which appears to include some memory related improvements.

Not sure if this change is what impacted your improvement, but it's at least good to know. Thanks again.

[korya]

We faced a similar problem with webpack-dev-server. Using a more aggressive policy for CommonsChunk plugin reduced memory usage from 1.8GB to 1.1GB, minChunks was set to 3 to include most of the shared code:

    new webpack.optimize.CommonsChunkPlugin({
      name: 'common',
      filename: 'common.js',
      minChunks: 3,
    }),

Is there a way to disable the usage of memory of FS and to use regular file system?

[EddyVerbruggen]

My situation may be a bit specific, but I had a few very large .d.ts files in the project that caused the webpack build to fail all the time (out of memory). Adding skipLibCheck: true to tsconfig.json fixed that.

[keyiis]

I had same issues, i set --max_old_space_size=4096 in webpack.cmd & gulp.cmd,but no effect,this issues only happen in production,maybe because use hash file name. additional: I used webpack with gulp,it has three webpack task in gulpfile,if i manual run task standalone,all work fine,but run in gulp task,the memory sustained growth,it seems not release memory after one task end.

[alan-agius4]

I have same issue, though I am using ionic app scripts, with webpack 3.0 the memory spikes up to 5gb and the process dies. With webpack 2 it used to be ok

[remojansen]

Just upgraded to webpack 3.0 and experiencing leaks as well:

16:17:03 - File change detected. Starting incremental compilation...

<--- Last few GCs --->

[26089:0x3d30680]    47717 ms: Mark-sweep 1402.9 (1470.8) -> 1400.8 (1472.8) MB, 891.8 / 0.0 ms  allocation failure GC in old space requested
[26089:0x3d30680]    48960 ms: Mark-sweep 1400.8 (1472.8) -> 1400.8 (1472.8) MB, 1243.3 / 0.0 ms  allocation failure GC in old space requested
[26089:0x3d30680]    50225 ms: Mark-sweep 1400.8 (1472.8) -> 1400.8 (1442.8) MB, 1264.0 / 0.0 ms  last resort 
[26089:0x3d30680]    51476 ms: Mark-sweep 1400.8 (1442.8) -> 1400.8 (1442.8) MB, 1251.0 / 0.0 ms  last resort 

<--- JS stacktrace --->

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

Security context: 0x1c3674e29891 <JS Object>
    2: encodeLastRecordedSourceMapSpan [/home/rjansen/CODE/core/node_modules/typescript/lib/tsc.js:~50611] [pc=0xdef7f5f96d8](this=0x264e5bcb27a1 <JS Global Object>)
    3: emitPos [/home/rjansen/CODE/core/node_modules/typescript/lib/tsc.js:~50639] [pc=0xdef7f5525d1](this=0x264e5bcb27a1 <JS Global Object>,pos=0x2caa051c92e9 <Number: 5.37458e+06>)
    4: emitNodeWithSourceMap [/home/rjansen/CODE...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
 1: node::Abort() [node]
 2: 0x13647ec [node]
 3: v8::Utils::ReportOOMFailure(char const*, bool) [node]
 4: v8::internal::V8::FatalProcessOutOfMemory(char const*, bool) [node]
 5: v8::internal::Factory::NewUninitializedFixedArray(int) [node]
 6: 0xe90ca3 [node]
 7: v8::internal::Runtime_GrowArrayElements(int, v8::internal::Object**, v8::internal::Isolate*) [node]
 8: 0xdef7de0437d
Aborted
npm ERR! code ELIFECYCLE
npm ERR! errno 134
npm ERR! core@1.0.0 watch-server: `tsc -p tsconfig.json -inlineSourceMap -outDir private --watch`
npm ERR! Exit status 134

[irowbin]

After every 5-6 build on dev mode including--hot --inline --progress --colors --port 2000 , i got this FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory

webpack v3.1.0

webpack-dev-server v2.5.1

[krbaio3]

I have same issues, when I build with npm run clean && webpack --display-error-details, I got this:

<--- Last few GCs --->

  164635 ms: Mark-sweep 1275.2 (1434.0) -> 1275.2 (1434.0) MB, 1446.8 / 0.0 ms [allocation failure] [GC in old space requested].
  166101 ms: Mark-sweep 1275.2 (1434.0) -> 1275.2 (1434.0) MB, 1465.7 / 0.0 ms [allocation failure] [GC in old space requested].
  167625 ms: Mark-sweep 1275.2 (1434.0) -> 1280.3 (1413.0) MB, 1523.3 / 0.1 ms [last resort gc].
  169164 ms: Mark-sweep 1280.3 (1413.0) -> 1285.7 (1413.0) MB, 1538.1 / 0.0 ms [last resort gc].

<--- JS stacktrace --->

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

Security context: 00000168FC0CFB61 <JS Object>
    1: map [native array.js:~994] [pc=000002493CE23EA3] (this=000003E091F1A8A1 <JS Array[1]>,bq=0000031BDD71D189 <JS Function (SharedFunctionInfo 000002FDA0B639D1)>,br=00000168FC004381 <undefi
ned>)
    2: arguments adaptor frame: 1->2
    3: new BasicSourceMapConsumer [C:\Users\a181226\Documents\cancelacion-webpack\node_modules\source-map\lib\source-map-consumer.js:314] [pc=000002493EBB3B52] ...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory

I use webpack 2.6.1

[ayozebarrera]

Same issue

<--- Last few GCs --->

 7076693 ms: Scavenge 1416.9 (1472.9) -> 1416.9 (1472.9) MB, 3.9 / 0 ms (+ 5.4 ms in 1 steps since last GC) [allocation failure] [incremental marking delaying mark-sweep].
 7077971 ms: Mark-sweep 1416.9 (1472.9) -> 1403.9 (1459.8) MB, 1278.4 / 0 ms (+ 9.1 ms in 2 steps since start of marking, biggest step 5.4 ms) [last resort gc].
 7079257 ms: Mark-sweep 1403.9 (1459.8) -> 1403.9 (1459.8) MB, 1285.9 / 0 ms [last resort gc].

<--- JS stacktrace --->

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

Security context: 0x2fb44c1e3ac1 <JS Object>
    2: toString [/home/abarrera/Proyectos/front-sae/node_modules/webpack/lib/Stats.js:411] [pc=0x24c131efa4ef] (this=0x3546c1922b51 <a Stats with map 0x38d80a68ee9>,options=0x2513409b01f9 <an Object with map 0x1ad3a812ccc1>)
    3: handler(aka compilerCallback) [/home/abarrera/Proyectos/front-sae/node_modules/webpack/bin/webpack.js:348] [pc=0x24c131efa08d] (this=0x2513409b3071 <a Watching with ...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - process out of memory

Command used webpack --watch --progress

Webpack v3.2.0

Node v5.12.0

[fxck]

Having this problem as well. Tried couple of things like disabling uglification for a while, to no avail. It gets stuck 92% chunk asset optimization for a while and then throws that FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory. Tried using https://www.npmjs.com/package/increase-memory-limit didn't get either. I don't know anymore.

[stephenlacy]

Also getting this, OOM error:

[28798:0x3a4d6c0]   533443 ms: Mark-sweep 1379.0 (1544.1) -> 1378.9 (1543.1) MB, 439.8 / 0.0 ms  allocation failure GC in old space requested
[28798:0x3a4d6c0]   533926 ms: Mark-sweep 1378.9 (1543.1) -> 1378.9 (1497.6) MB, 482.9 / 0.0 ms  last resort 
[28798:0x3a4d6c0]   534372 ms: Mark-sweep 1378.9 (1497.6) -> 1378.7 (1484.6) MB, 445.6 / 0.1 ms  last resort 

<--- JS stacktrace --->                       

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

Security context: 0x130e83a266a1 <JS Object>  
    1: DoJoin(aka DoJoin) [native array.js:~97] [pc=0x11ae132ebe76](this=0x147598602311 <undefined>,q=0x146650379c31 <JS Array[2]>,r=2,F=0x1475986023b1 <true>,B=0x147598602471 <String[0]: >,A=0x147598602421 <false>)
    2: Join(aka Join) [native array.js:~122] [pc=0x11ae130f8622](this=0x147598602311 <undefined>,q=0x146650379c31 <JS Array[2]>,r=2,B=0x147598602471 <String[0]: >,A=0x147598602421 <...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory           
 1: node::Abort() [node]                      
 2: 0x12b82ac [node]   
 3: v8::Utils::ReportOOMFailure(char const*, bool) [node]                                    
 4: v8::internal::V8::FatalProcessOutOfMemory(char const*, bool) [node]                      
 5: v8::internal::Factory::NewRawTwoByteString(int, v8::internal::PretenureFlag) [node]      
 6: v8::internal::Runtime_StringBuilderConcat(int, v8::internal::Object**, v8::internal::Isolate*) [node]
 7: 0x11ae0fc843a7     
Aborted                

[camsjams]

Seems related to Webpack 3 upgrade for me as well

On Node v8.1.2 with upgrade from webpack@2.4.1 => webpack@3.0.0 caused much slowdown and the CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory error.

Upon doing: rm -rf node_modules and then npm install with webpack@2.4.1, the problem goes away, and compiling/build times are dramatically reduced.

[stephenlacy]

My error is directly related to: #5089

[alan-agius4]

@stevelacy same here man. Have an issue https://github.com/webpack/webpack/issues/5257