Parcel: Parcel memory leak crash after a few HMRs

[natew]

bug reprot

Basically, parcel 1.6 crashes pretty consistently for me when saving files in a medium-large app that uses HMR.

The stack is as follows:

<--- Last few GCs --->

[1273:0x103800000]  3702603 ms: Mark-sweep 1369.2 (1452.7) -> 1368.5 (1460.7) MB, 1416.1 / 0.0 ms  allocation failure GC in old space requested
[1273:0x103800000]  3703648 ms: Mark-sweep 1368.5 (1460.7) -> 1368.4 (1429.7) MB, 1044.4 / 0.0 ms  last resort GC in old space requested
[1273:0x103800000]  3704689 ms: Mark-sweep 1368.4 (1429.7) -> 1368.4 (1429.7) MB, 1040.5 / 0.0 ms  last resort GC in old space requested


<--- JS stacktrace --->

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

Security context: 0x224ac1d25529 <JSObject>
    0: builtin exit frame: stringify(this=0x224ac1d08d59 <Object map = 0x224a7a102ba1>,0x224ab5b022d1 <undefined>,0x224ab5b022d1 <undefined>,0x224a8a01f831 <Object map = 0x224a3f4a9d41>)

    1: arguments adaptor frame: 1->3
    2: toString(aka SourceMapGenerator_toString) [/Users/nw/projects/motion/orbit/node_modules/parcel-bundler/node_modules/source-map/lib/source-map-generator.js:422] [bytec...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
 1: node::Abort() [/Users/nw/n/bin/node]
 2: node::FatalTryCatch::~FatalTryCatch() [/Users/nw/n/bin/node]
 3: v8::internal::V8::FatalProcessOutOfMemory(char const*, bool) [/Users/nw/n/bin/node]
 4: v8::internal::Factory::NewRawOneByteString(int, v8::internal::PretenureFlag) [/Users/nw/n/bin/node]
 5: v8::internal::String::SlowFlatten(v8::internal::Handle<v8::internal::ConsString>, v8::internal::PretenureFlag) [/Users/nw/n/bin/node]
 6: v8::internal::JsonStringifier::SerializeString(v8::internal::Handle<v8::internal::String>) [/Users/nw/n/bin/node]
 7: v8::internal::JsonStringifier::Result v8::internal::JsonStringifier::Serialize_<true>(v8::internal::Handle<v8::internal::Object>, bool, v8::internal::Handle<v8::internal::Object>) [/Users/nw/n/bin/node]
 8: v8::internal::JsonStringifier::Result v8::internal::JsonStringifier::Serialize_<false>(v8::internal::Handle<v8::internal::Object>, bool, v8::internal::Handle<v8::internal::Object>) [/Users/nw/n/bin/node]
 9: v8::internal::JsonStringifier::Stringify(v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::Object>) [/Users/nw/n/bin/node]
10: v8::internal::Builtin_Impl_JsonStringify(v8::internal::BuiltinArguments, v8::internal::Isolate*) [/Users/nw/n/bin/node]
11: 0x367c4b50697d
12: 0x367c4b50535f
13: 0x367c4b5bd196
14: 0x367c4b5bd196
15: 0x367c4b5bd196

🎛 Configuration (.babelrc, package.json, cli command)

{
  "your": { "config": "here" }
}

🤔 Expected Behavior

Not crashing

Unfortunately, this one is hard for me to help you guys with without doing a more intense profile on the running process. The app is complex, and it only happens usually after a few HMRs.

Separately, tried updating to 1.7 but it won't run our stack anymore (forget the error).

🌍 Your Environment

| Software | Version(s) |
| ---------------- | ---------- |
| Parcel | 1.6.1
| Node | 9.8
| npm/Yarn | yarn 1.5.1
| Operating System | high sierra

[devongovett]

How big is your app, e.g. how many files + node_modules?

[natew]

Good question, any way to get parcel to spit it out?

[DeMoorJasper]

@natew You could use this option https://parceljs.org/cli.html#print-a-detailed-report using a build command to get all the requires and sizes parcel processes.
Although this will probably not be possible as in your case parcel crashes before even reaching that point?

[natew]

Ah cool will run that soon. It only crashes after using it for a few HMRs
so should be fine to print.

[natew]

Not sure if this is super helpful, is there perhaps an expanded form flag to print? For reference, it was crashing before typeorm, even though that seems to take a lot of it up now.

Profiling HMR specifically would be helpful, but not in the browser on the node side. I could maybe wrap some code to help see.

[samsartor]

I am also having this issue.

• Parcel v1.7.0
• Yarn v1.6.0
• Node v9.11.1
• Arch Linux

> yarn run parcel build index.html --public-url ./
yarn run v1.6.0
$ /home/example/project/node_modules/.bin/parcel build index.html --public-url ./
⏳  Building interpolate.js...

<--- Last few GCs --->

[12058:0x55777adb7750]    55066 ms: Mark-sweep 1359.1 (1466.9) -> 1358.9 (1468.4) MB, 1503.8 / 0.0 ms  allocation failure GC in old space requested
[12058:0x55777adb7750]    56660 ms: Mark-sweep 1358.9 (1468.4) -> 1358.9 (1434.4) MB, 1594.1 / 0.0 ms  last resort GC in old space requested
[12058:0x55777adb7750]    58304 ms: Mark-sweep 1358.9 (1434.4) -> 1358.9 (1434.4) MB, 1643.0 / 0.0 ms  last resort GC in old space requested


<--- JS stacktrace --->

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

Security context: 0x18d7174a55e9 <JSObject>
    1: expr_op(aka expr_op) [0x4cb31c022d1 <undefined>:~4338] [pc=0x1142f64dd2b7](this=0x4cb31c022d1 <undefined>,left=0x24e44ce0d531 <AST_SymbolRef map = 0x214e6608559>,min_prec=0,no_in=0x4cb31c022d1 <undefined>)
    2: expression(aka expression) [0x4cb31c022d1 <undefined>:~4462] [pc=0x1142f64e532c](this=0x4cb31c022d1 <undefined>,commas=0x4cb31c02371 <true>,no_in=0x4cb31c022d1 <undefined>)
    3...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
 1: node::Abort() [node]
 2: 0x557778e03a6f [node]
 3: v8::Utils::ReportOOMFailure(char const*, bool) [node]
 4: v8::internal::V8::FatalProcessOutOfMemory(char const*, bool) [node]
 5: v8::internal::Factory::NewCode(v8::internal::CodeDesc const&, unsigned int, v8::internal::Handle<v8::internal::Object>, bool, int) [node]
 6: v8::internal::CodeGenerator::MakeCodeEpilogue(v8::internal::TurboAssembler*, v8::internal::EhFrameWriter*, v8::internal::CompilationInfo*, v8::internal::Handle<v8::internal::Object>) [node]
 7: v8::internal::compiler::CodeGenerator::FinalizeCode() [node]
 8: v8::internal::compiler::PipelineImpl::FinalizeCode() [node]
 9: v8::internal::compiler::PipelineCompilationJob::FinalizeJobImpl() [node]
10: v8::internal::CompilationJob::FinalizeJob() [node]
11: v8::internal::Compiler::FinalizeCompilationJob(v8::internal::CompilationJob*) [node]
12: v8::internal::OptimizingCompileDispatcher::InstallOptimizedFunctions() [node]
13: v8::internal::StackGuard::HandleInterrupts() [node]
14: v8::internal::Runtime_StackGuard(int, v8::internal::Object**, v8::internal::Isolate*) [node]
15: 0x1142f62842fd
error Command failed with signal "SIGABRT".
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

I can't print out a report because parcel build index.html --detailed-report crashes too.

package.json:

{
  "main": "index.js",
  "dependencies": {
    "d3": "^5.1.0",
    "d3-graphviz": "^1.6.1",
    "parcel-bundler": "1.7.0",
    "parcel-plugin-cargo-web": "^0.2.0"
  }
}

Just running parcel index.html works fine, but I can't deploy that version.

[samsartor]

I also have a failing travis build.

Note that running yarn install before parcel build does not help. However, using --no-minify does prevent the error.

[rafaelrinaldi]

This seem to be related to #1513

[gimenete]

I've had the same problem and my workaround has been to use --no-cache. It seems to work now.

I just created a super basic app (100 lines of code) with http://ant.design/ and firebase

[alidlorenzo]

I have a similar problem. Along with random Object prototype may only be an Object or null: undefined errors (#1181), I'm getting warnings about memory leaks, e.g. MaxListenersExceededWarning: Possible EventEmitter memory leak detected. So sometimes my app starts, sometimes it doesn't.

edit: I was running a client and server bundle at the same time, running one at a time helped

[mzabsky]

Confirming this issue. Just got:

<--- Last few GCs --->[24344:0000028F681B9D00] 93613091 ms: Mark-sweep 1369.8 (1432.4) -> 1369.8 (1435.4) MB, 901.3 / 0.0 ms  allocation failure GC in old space requested
[24344:0000028F681B9D00] 93613962 ms: Mark-sweep 1369.8 (1435.4) -> 1369.7 (1403.4) MB, 870.8 / 0.0 ms  last resort GC in old space requested
[24344:0000028F681B9D00] 93614848 ms: Mark-sweep 1369.7 (1403.4) -> 1369.7 (1403.4) MB, 885.0 / 0.0 ms  last resort GC in old space requested

<--- JS stacktrace --->

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

Security context: 000000346C325879 <JSObject>
    0: builtin exit frame: stringify(this=000000346C3090A9 <Object map = 0000004EF4082BA1>,000000449D9022D1 <undefined>,000000449D9022D1 <undefined>,000002A827B95B21 <Object map = 000002F0E80A6A61>)

    1: arguments adaptor frame: 1->3
    2: toString(aka SourceMapGenerator_toString) [C:\Users\matej.zabsky\Desktop\lung\node_modules\parcel-bundler\node_modules\source-map\lib\source-map-generat...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
 1: node_module_register
 2: v8::internal::FatalProcessOutOfMemory
 3: v8::internal::FatalProcessOutOfMemory
 4: v8::internal::Factory::NewRawOneByteString
 5: v8::internal::Smi::SmiPrint
 6: v8::internal::StackGuard::HandleInterrupts
 7: v8::internal::wasm::LocalDeclEncoder::Size
 8: v8::internal::wasm::LocalDeclEncoder::Size
 9: v8::internal::wasm::LocalDeclEncoder::Size
10: v8_inspector::protocol::Debugger::API::SearchMatch::fromJSONString
11: v8_inspector::protocol::Debugger::API::SearchMatch::fromJSONString
12: 00000390E0686B21
error Command failed with exit code 3.

While I am not getting this particular message too consistently, parcel builds consistenly slow down over time when using HMR. This becomes noticeable as soon as after 15 min of normal development. It is not a big issue though, restarting parcel takes 10 seconds.

My project is a React+Redux app, it has 773 folders in node_modules totaling about 100 MB. I can provide more info, if needed, but I cannot share the complete source code.

--no-cache helps, but slows down development much more than just restarting parcel every now and then.

[DeMoorJasper]

@mzabsky can you try out the latest master branch using git. It might have been related to this: #1755 as the stacktrace mentions sourcemaps

[kennetpostigo]

I reproduce this on master as well with a really long json file.

[DeMoorJasper]

It might be because we inline all the sources inside the sourcemap. Can you check using --no-source-maps.
I don't think this is really a memory leak.
It might be just how sourcemaps works (the library) and as the JS version has been depricated, we might have to branch of their project to create a streaming stringifier or something idk.

In Parcel 2 we keep the code in memory for a very short period of time so if we continue that pattern inside the sourcemaps (in combination with a streaming json stringifier), it would solve this issue (if that is the issue).

[kennetpostigo]

@DeMoorJasper disabled source maps and it still seems to happen. Is there anyway to tell parcel "don't bundle this, I know what I'm doing"?

[DeMoorJasper]

@kennetpostigo not sure, in most stacktraces I saw in this issue it occurs in sourcemap-generator, so it is probably related to sourcemaps for those issues. If you could post your stacktrace it would help a lot (the one without sourcemaps)

[vikingmute]

Hey guys, I ran into the same issue, my files are super simple, it's a regular javascript file and html file, and I just wanna set up a development server with HMR.

I tried

parcel index.html --no-cache

not working, the error came up after several minutes.

parcel index.html --no-source-maps

not working, same issue.

Parcel: 1.10.3
Node: 8.11.3
MacOS Mojave 10.14

[andrewjrhill]

Experiencing the same issue. Codebase has a large number of dependencies which is what I imagine is causing the crash.

[abdul737]

Hey everyone!
Thanks to @DeMoorJasper, This worked for me:

parcel index.html --no-source-maps

I was including my own custom npm lib which was the size of more than 4MB build, and in both projects I used parcel. Now I have no error. Thanks

[embeddedt]

I was running into a similar issue with a moderately large Parcel project. Parcel would consistently eat all of my RAM (6GB) whenever I started it.

After reading through many issues I found this one. Using @DeMoorJasper's suggestion (--no-source-maps) seems to have entirely fixed the problem, though at the cost of easily viewing stack traces.

Is there a way to enable source maps just for my code and not for any code inside node_modules? That way the final source map would be much smaller.

[DeMoorJasper]

@embeddedt unfortunately not.

Parcel 2 has a lot of improvements when it comes to ram usage, including only reading sourcefiles when needed for sourcemaps, which is when the sourcemaps get written if inline-sources is enabled which is only the default in production as we now mount the sources in the dev server. So it should be fixed for Parcel 2. Unfortunately there's no workaround for Parcel 1 besides turning of sourcemaps

[embeddedt]

I see. That's too bad.

Is Parcel 2 stable enough yet for production? I noticed that public testing opened up a few days ago.

[DeMoorJasper]

@embeddedt it's not stable enough to use in production. But any feedback and bugs discovered on larger codebases are very welcome

[embeddedt]

It turns out that VSCode's function name autocompletion had inadvertently added an import statement for a very large module which I never used anywhere in my project. Once I removed that module, I was able to start using source maps again with little to no RAM impact.

So my suggestion is: for those who are still using Parcel 1, check your bundles using source-map-analyzer or parcel build --detailed-report to see if you are importing some large module which you don't need. If you are, removing it will probably fix the issue.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs.