parcel: Parcel memory leak crash after a few HMRs

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

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Reactions: 10
  • Comments: 25 (7 by maintainers)

Most upvoted comments

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

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

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).