Parcel sometimes fails to start properly
Closed this issue · 20 comments
🐛 bug report
He can sometimes work, sometimes he can't work.
When I remove the scss file it may improve, but I'm not sure if the problem is there.
Perhaps it is related to the loading mechanism of the module?
Faster processing when there are fewer modules, When the number of modules is large, the dependency is more complicated and the relationship is not handled properly, Causes the process to exit abnormally.
🎛 Configuration (.babelrc, package.json, cli command)
{
"name": "parcel",
"version": "1.0.0",
"scripts": {
"dev": "parcel ./src/view/*.html"
},
"devDependencies": {
"node-sass": "^4.9.0",
"parcel-bundler": "^1.8.1"
}
}
🤔 Expected Behavior
Normal start work
😯 Current Behavior
Sometimes quit abnormally
Comparison of loading scss files and removing scss
🔦 Context
parcel ./src/view/*.htmlyarn run v1.5.1
$ parcel ./src/view/*.html
Server running at http://localhost:1234
⏳ Building hmr-runtime.js...
error An unexpected error occurred: "Command failed.
Exit signal: SIGSEGV
Command: sh
Arguments: -c parcel ./src/view/*.html
Directory: /Users/WYH/Desktop/parcel
Output:
".
info If you think this is a bug, please open a bug report with the information provided in "/Users/WYH/Desktop/parcel/yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.💻 Code Sample
index.html :
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>Title</title>
<link rel="stylesheet" href="../style/index.scss">
</head>
<body>
hello world
</body>
</html>base.scss :
body{
background: red;
}index.scss :
@import './base.scss';
.btn{
width: 100px;
height: 38px;
border: 1px solid #ae2616;
color: #ae2616;
outline: none;
background-color: transparent;
cursor: pointer;
}🌍 Your Environment
| Software | Version(s) |
|---|---|
| Parcel | 1.8.1 |
| Node | 9.9.0 |
| npm/Yarn | 1.5.1 |
| Operating System | macOS High Soerra 10.13.4 |
i get this too in my create-react-app-parcel project. (just the base template, nothing fancy at all). its super weird, 1 out of 20 times it will run. there is a segfault somewhere and I don't know how to debug it further:
after doing something else for awhile and then coming back, this problem goes away. so there seems to be some memory lock on something that then gets garbage'd away? not really knowing the internals of parcel I don't even know how to track this down further than the SIGSEGV error.
This problem does not occur when using parcel build
right, so its a parcel or parcel watch problem. i still can't track it down but its more intermittent for me now. any one have ideas on how to reliably reproduce this kind of segfault error?
I'm currently having this same issue again, I'm 99% sure this is a SASS issue, as it only happens once I've added scss files to my build pipeline.
EDIT: Just converted my sass styles into less styles and it still fails, but at least it's not consistent now
This is a full stacktrace I've managed to extract using segfault-handler
PID 88808 received SIGSEGV for address: 0x0
0 segfault-handler.node 0x00000001022f0168 _ZL16segfault_handleriP9__siginfoPv + 280
1 libsystem_platform.dylib 0x00007fff7ecc2f5a _sigtramp + 26
2 ??? 0x000000010fdac088 0x0 + 4560961672
3 fse.node 0x00000001022d8467 _ZN3fse8FSEventsD2Ev + 91
4 fse.node 0x00000001022d8514 _ZN3fse8FSEventsD0Ev + 14
5 node 0x00000001004ca603 _ZN2v88internal13GlobalHandles31DispatchPendingPhantomCallbacksEb + 147
6 node 0x00000001004ca931 _ZN2v88internal13GlobalHandles31PostGarbageCollectionProcessingENS0_16GarbageCollectorENS_15GCCallbackFlagsE + 49
7 node 0x00000001004e0399 _ZN2v88internal4Heap24PerformGarbageCollectionENS0_16GarbageCollectorENS_15GCCallbackFlagsE + 2665
8 node 0x00000001004df2b5 _ZN2v88internal4Heap14CollectGarbageENS0_15AllocationSpaceENS0_23GarbageCollectionReasonENS_15GCCallbackFlagsE + 853
9 node 0x00000001004a0992 _ZN2v88internal7Factory15NewFillerObjectEibNS0_15AllocationSpaceE + 82
10 node 0x000000010076a665 _ZN2v88internal26Runtime_AllocateInNewSpaceEiPPNS0_6ObjectEPNS0_7IsolateE + 101
11 ??? 0x00001a12704042fd 0x0 + 28666494993149
If everyone in this issue is using MAC OS X I think this is an fsevents bug?
fse.node appears to be a file related to fsevents
Might be related to this issue: fsevents/fsevents#218
yes i'm using macosx.
i have a confession.. how do you use segfault-handler in the context of parcel? their readme doesn't exactly hold your hand through it...
You simple put require('segfault-handler').registerHandler(); at the start of the bundler.js file
Than it throws the detailed report and writes that report to the cwd
No problem, I'll do a PR that should fix this in a few mins
@tsiq-swyx also if you turn on core dumps at the start of a terminal session, you can use llnode to capture the JS backtrace and post the stack frame with unmasked JS frames, without segfault-handler (I've had issues with segfault-handler in node10 recently). This post is a good intro on how to use llnode to inspect the core dump: https://developer.ibm.com/node/2016/08/15/exploring-node-js-core-dumps-using-the-llnode-plugin-for-lldb/
I'm about to start a new project with create-react-app-parcel, and will post the stack trace here if I encounter this too.
thanks, confusingly it just works every time now. hard to replicate this but i'll keep this issue open on c-r-a-p.
When is the planned release date for the next version with the fix incorporated? This is consistently reproducible for me using the current latest version (1.8.1, same as in this original report).
Exactly the same problem here. It's been happening a lot this morning.
same problem here, as of november
Same here:
> yarn build
yarn run v1.22.19
warning package.json: No license field
$ parcel build
error Command failed with signal "SIGSEGV".
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
I am using parcel 2.11.0
It is still happening in v2.12.0 :/
Don't know if is not related, but moving to a parent directory and coming back to the project dir and the command worked :/
The problem still exists.
The following information may be useful:
node(42005,0x16fadf000) malloc: Incorrect checksum for freed object 0x13c0dfa00: probably modified after being freed.
Corrupt value: 0x3361636366393331
node(42005,0x16fadf000) malloc: *** set a breakpoint in malloc_error_break to debug
error Command failed with exit code 1.This problem seems to be the same: #9926 .