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)
Hey everyone! Thanks to @DeMoorJasper, This worked for me:
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
not working, the error came up after several minutes.
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).