parcel-bundler / parcel

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

Segfault introduced in 2.9.0 #9670

Open mpmartinez-etsy opened 5 months ago

mpmartinez-etsy commented 5 months ago

🐛 bug report

Heya folks, just thought I'd report there seems to be a deterministic segfault with this example repository. I've been able to reproduce this issue in every version of parcel from 2.90 to 2.12.0 (latest). I was able to reproduce this issue on Centos7 with node16.13.2, Ubuntu22.04.4 LTS with node20, and Mac OS X 14.2.1 with node16.20.2 - I'm happy to provide more information about any versions that are necessary, please let me know.

It's worth pointing out that this doesn't happen in parcel 2.8.3 - I haven't checked lower, as this version will be fine for our purposes.

Also, worth pointing out that while I did a cursory scan of previously open issues, and indeed found some closed that were related to segfaults, I couldn't find one describing this particular issue. Please feel free to close if this isn't relevant for your purposes.

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

provided in link above, but will paste here as well:

package.json:

{
  "dependencies": {
    "@preact/legacy-compat": "0.2.0",
    "parcel": "2.12.0",
    "preact": "10.13.1"
  },
  "devDependencies": {
        "@types/react": "17.0.39"
  }
}

tsconfig.json:

{
    "compilerOptions": {
        "paths": {
            "preact/compat": [
                "node_modules/@types/react",
                "preact/compat"
            ]
        }
    }
}

example.tsx:

import { useState } from "preact/compat";
useState(false);

build.mjs:

import { Parcel } from '@parcel/core';

const entries = ["example.tsx"];
console.log("building entries:\n" + entries);

const bundler = new Parcel({
        entries: entries,
        defaultConfig: '@parcel/config-default'
      });
const result = await bundler.run();

(no babel config was explicitly necessary to produce the above behavior)

🤔 Expected Behavior

Parcel shouldn't segfault (if something is wrong with the config, parcel should raise that up to the user).

😯 Current Behavior

Parcel segfaults with no additional information

-bash-4.2$ node build.mjs
building entries:
example.tsx
Segmentation fault

💁 Possible Solution

none at this time

🔦 Context

We are testing parcel for use as a javascript bundler, and wanted to prove out the utility of it and hit this (admittedly with our rather arcane tsconfig/react/preact setup). We can drop down to a lower version to continue proving out utility, so no worries there, just figured that the reproducibility here might be useful

💻 Code Sample

https://github.com/mpmartinez-etsy/parcel-segfault-example

🌍 Your Environment

Software Version(s)
Parcel 2.12.0
Node 16 & 20
npm/Yarn yarn 1.22.15
Operating System Ubuntu22, Centos7, MacOSx
mischnic commented 5 months ago

We are testing parcel for use as a javascript bundler, and wanted to prove out the utility of it

Also feel free to ask for help if you run into any other problems (e.g. regarding configuration), for example in the Github Discussions or on Discord!

mischnic commented 5 months ago

This is apparently an infinite recursion in the resolver when resolving preact/compat with preact@10.13.1

    frame #1088: 0x00000001700383e4 parcel-node-bindings.darwin-x64.node`parcel_resolver::ResolveRequest$LT$Fs$GT$::load_directory::ha2f04ad6884058f7(self=0x00007000113ddf00, dir=&std::path::Path @ 0x0000700011297f30, parent_package=Option<&parcel_resolver::package_json::PackageJson> @ 0x0000700011297f40) at lib.rs:1066:13
    frame #1089: 0x0000000170040410 parcel-node-bindings.darwin-x64.node`parcel_resolver::ResolveRequest$LT$Fs$GT$::load_path::h88788c6ab2097b24(self=0x00007000113ddf00, path=&std::path::Path @ 0x0000700011298178, package=Option<&parcel_resolver::package_json::PackageJson> @ 0x0000700011298188) at lib.rs:814:14
    frame #1090: 0x000000017003bae7 parcel-node-bindings.darwin-x64.node`parcel_resolver::ResolveRequest$LT$Fs$GT$::try_package_entries::h4c6361f3dd113d58(self=0x00007000113ddf00, package=0x0000000103fd4600) at lib.rs:774:26

    frame #1091: 0x00000001700383e4 parcel-node-bindings.darwin-x64.node`parcel_resolver::ResolveRequest$LT$Fs$GT$::load_directory::ha2f04ad6884058f7(self=0x00007000113ddf00, dir=&std::path::Path @ 0x0000700011298730, parent_package=Option<&parcel_resolver::package_json::PackageJson> @ 0x0000700011298740) at lib.rs:1066:13
    frame #1092: 0x0000000170040410 parcel-node-bindings.darwin-x64.node`parcel_resolver::ResolveRequest$LT$Fs$GT$::load_path::h88788c6ab2097b24(self=0x00007000113ddf00, path=&std::path::Path @ 0x0000700011298978, package=Option<&parcel_resolver::package_json::PackageJson> @ 0x0000700011298988) at lib.rs:814:14
    frame #1093: 0x000000017003bae7 parcel-node-bindings.darwin-x64.node`parcel_resolver::ResolveRequest$LT$Fs$GT$::try_package_entries::h4c6361f3dd113d58(self=0x00007000113ddf00, package=0x0000000103fd4600) at lib.rs:774:26

    frame #1094: 0x00000001700383e4 parcel-node-bindings.darwin-x64.node`parcel_resolver::ResolveRequest$LT$Fs$GT$::load_directory::ha2f04ad6884058f7(self=0x00007000113ddf00, dir=&std::path::Path @ 0x0000700011298f30, parent_package=Option<&parcel_resolver::package_json::PackageJson> @ 0x0000700011298f40) at lib.rs:1066:13
    frame #1095: 0x0000000170040410 parcel-node-bindings.darwin-x64.node`parcel_resolver::ResolveRequest$LT$Fs$GT$::load_path::h88788c6ab2097b24(self=0x00007000113ddf00, path=&std::path::Path @ 0x0000700011299178, package=Option<&parcel_resolver::package_json::PackageJson> @ 0x0000700011299188) at lib.rs:814:14
    frame #1096: 0x000000017003bae7 parcel-node-bindings.darwin-x64.node`parcel_resolver::ResolveRequest$LT$Fs$GT$::try_package_entries::h4c6361f3dd113d58(self=0x00007000113ddf00, package=0x0000000103fd4600) at lib.rs:774:26

    frame #1097: 0x00000001700383e4 parcel-node-bindings.darwin-x64.node`parcel_resolver::ResolveRequest$LT$Fs$GT$::load_directory::ha2f04ad6884058f7(self=0x00007000113ddf00, dir=&std::path::Path @ 0x0000700011299730, parent_package=Option<&parcel_resolver::package_json::PackageJson> @ 0x0000700011299740) at lib.rs:1066:13
    frame #1098: 0x0000000170040410 parcel-node-bindings.darwin-x64.node`parcel_resolver::ResolveRequest$LT$Fs$GT$::load_path::h88788c6ab2097b24(self=0x00007000113ddf00, path=&std::path::Path @ 0x0000700011299978, package=Option<&parcel_resolver::package_json::PackageJson> @ 0x0000700011299988) at lib.rs:814:14
    frame #1099: 0x000000017003bae7 parcel-node-bindings.darwin-x64.node`parcel_resolver::ResolveRequest$LT$Fs$GT$::try_package_entries::h4c6361f3dd113d58(self=0x00007000113ddf00, package=0x0000000103fd4600) at lib.rs:774:26
mischnic commented 4 months ago

It's actually unrelated to preact. This tsconfig

{
    "compilerOptions": {
        "paths": {
            "preact/compat": [
                "node_modules/@types/react",
                "preact/compat"
            ]
        }
    }
}

includes https://unpkg.com/browse/@types/react@17.0.39/package.json which in that specific version had a invalid "main": "" entry. That causes the infinite loop