search

parcel-bundler / parcel

The zero configuration build tool for the web. 📦🚀
https://parceljs.org
MIT License
43.47k stars 2.27k forks source link

Bundler freezes since 1.8.0 #1331

Closed jpergler closed 6 years ago

jpergler commented 6 years ago

🐛 Bug report

🤔 Expected Behavior

The bundler should finish the process.

😯 Current Behavior

Bundler freezes on build and does not finish at all. Previously I had version 1.7.0 and sometimes it was frozen as well but that was only several times and when restarted it mostly worked. After upgrade to version 1.8.1 I tried to build approx. 20 times but it did not finish at all. No changes in project. I tried version 1.8.0 and it did not work either.

🔦 Context

My project is just index.html with references scripts. Typescript is used in project. App based on React and Bootstrap.

🌍 Your Environment

Software Version(s)
Parcel ^1.8.0
Node 9.11.1
npm 5.6.0
Operating System Windows 10
fathyb commented 6 years ago

Could you try Node.js nightly? A bug was fixed a few weeks ago in libuv that resulted in freezes on Windows (libuv/libuv@4e53af9)

Hammster commented 6 years ago

@fathyb still freezes with the nightly you gave me. It went a little further the pipeline though.

....
∞  Building container.vue...
∞  Building resizer.vue...
∞  Building stats.vue...
∞  Building vue.runtime.esm.js...
∞  Building index.js...
∞  Building index.vue...
∞  Building index.vue...
∞  Building index.vue...
∞  Building index.vue...    <=== crashed here before
∞  Building svgicon.vue...
∞  Building command.vue...
∞  Building symbols.svg...
fathyb commented 6 years ago

Ah, it may be something else then. A reproduction could help for this one, weird that we have that many possible causes for freezes.

Ah and just in case, you used --no-cache or removed the .cache directory right?

Hammster commented 6 years ago

Indeed, i'll try to reproduce this but it may take some time to find the culprit 🕵🔎 Also clearing the .cache and deactivating watch + hmr did not change the results.

benhutton commented 6 years ago

@fathyb FWIW, I'm running ubuntu, not windows, and seeing freezing. I wonder if there's a number of different (and possibly related?) things happening?

Hammster commented 6 years ago

@benhutton could you try to modfiy this line https://github.com/parcel-bundler/parcel/blob/cc6018ebcb6bb068246ef77c0aa2ee227e11c7b4/src/workerfarm/WorkerFarm.js#L13

If i set this to a value between 1 and 3, it builds without freezing. I am sure the issues is somewhere else though and this this just avoids the resulting issue.

DeMoorJasper commented 6 years ago

Could we move the new problems into new issues pls. This issue is getting very cluttered and already has solved 2 different bugs.

andrykonchin commented 6 years ago

@Hammster 's advise works for me. Thanks.

There is a new env variable PARCEL_MAX_CONCURRENT_CALLS (in the latest 1.9.4 release) to set this concurrent calls limit.

jayprado commented 6 years ago

Setting PARCEL_MAX_CONCURRENT_CALLS=3 env variable also worked for me, on "parcel-bundler": "1.9.6", and node v8.11.3.

mnpenner commented 2 years ago

I'm still getting freezes with parcel@2.2.1 when I run parcel build on Win10 either through Powershell or WSL/Ubuntu.

Any workaround?

dohnuts commented 2 years ago

stracing the pid shows a problem , infinite looping in a futex

futex(0x6890100, FUTEX_WAKE_PRIVATE, 1) = 1 futex(0x68900b0, FUTEX_WAKE_PRIVATE, 1) = 1 futex(0x6890100, FUTEX_WAKE_PRIVATE, 1) = 1 futex(0x7ffa5f5cbb80, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable) futex(0x7ffa5f5cbb80, FUTEX_WAKE_PRIVATE, 1) = 0 futex(0x6890100, FUTEX_WAKE_PRIVATE, 1) = 1 getpid() = 1162014 mmap(0x214f21780000, 430080, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x214f21780000 munmap(0x214f217aa000, 258048) = 0 mprotect(0x214f21780000, 172032, PROT_READ|PROT_WRITE) = 0 mmap(0x381b98980000, 593920, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x381b98980000 munmap(0x381b989d2000, 258048) = 0 mprotect(0x381b98980000, 335872, PROT_READ|PROT_WRITE) = 0 mmap(0x2ad1f8ac0000, 430080, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2ad1f8ac0000 munmap(0x2ad1f8aea000, 258048) = 0 mprotect(0x2ad1f8ac0000, 172032, PROT_READ|PROT_WRITE) = 0 mmap(0x2b0b4580000, 921600, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x2b0b4580000 munmap(0x2b0b4622000, 258048) = 0 mprotect(0x2b0b4580000, 663552, PROT_READ|PROT_WRITE) = 0 mmap(0x12c7d4380000, 593920, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x12c7d4380000 munmap(0x12c7d43d2000, 258048) = 0 mprotect(0x12c7d4380000, 335872, PROT_READ|PROT_WRITE) = 0 mmap(0xebce2600000, 430080, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0xebce2600000 munmap(0xebce262a000, 258048) = 0 mprotect(0xebce2600000, 172032, PROT_READ|PROT_WRITE) = 0 mmap(0x11c85f340000, 593920, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x11c85f340000 munmap(0x11c85f392000, 258048) = 0 mprotect(0x11c85f340000, 335872, PROT_READ|PROT_WRITE) = 0 futex(0x6890100, FUTEX_WAKE_PRIVATE, 1) = 1 futex(0x68900e8, FUTEX_WAIT_PRIVATE, 3, NULL) = 0 futex(0x6890104, FUTEX_WAKE_PRIVATE, 1) = 1 futex(0x68900b0, FUTEX_WAKE_PRIVATE, 1) = 1 futex(0x713c7e0, FUTEX_WAIT_PRIVATE, 0, NULL) = 0 futex(0x713c768, FUTEX_WAKE_PRIVATE, 1) = 0 futex(0x6890104, FUTEX_WAKE_PRIVATE, 1) = 1 futex(0x68900b0, FUTEX_WAKE_PRIVATE, 1) = 1 getpid() = 1162014

maybe a read() badly managed or a bad use of a locking mechanism

Current LTS node node --version v16.15.0

things should work on LTS ;-)

I use PARCEL_MAX_CONCURRENT_CALLS=1 ... and 3 just in case

amusing

wait,

with PARCEL_WORKERS=0 yarn parcel build --log-level=verbose

it just took 20 mn to get unstuck from the Bundling task