Deadlock with the node API

[yoanthiebault]

First of all thank you for your amazing work, I have been hoping a long time for something faster and easier to use than webpack :)

I tried esbuild with the node API:

esbuild.buildSync({
	entryPoints: ["src/typescript/index.tsx"],
	bundle: true,
	minify: true,
	sourcemap: true,
	outfile: `build/${bundleName}.js`,
	define: {
	    "process.env.NODE_ENV": `\"${isProduction ? "production" : "development"}\"`
	},
	target: ["chrome58","firefox57","safari11","edge16"]
})

It works very well most of the time but I get sometimes a deadlock: the function runs but never ends. I also tried with the asynchronous esbuild.build method and got the same issue.

Nevertheless I succeed to avoid this deadlock by directly using esbuild.exe with child_process as you did in bin/esbuild:

const { status, error } = child_process.spawnSync(esbuild_exe, ["src/typescript/index.tsx",
    "--bundle", "--minify", "--sourcemap", `--outfile=build/${bundleName}.js`,
    `--define:process.env.NODE_ENV='${isProduction ? "production" : "development"}'`,
    "--target=chrome58,firefox57,safari11,edge16",
], { stdio: 'inherit' });

So I believe there is an issue in the way esbuild.exe is launched from the node API script.

I'm sorry I don't have more information to provide but I think it still may interest you if someone else encounters this deadlock issue.

FYI:
esbuild version: 0.8.30
node version: 10.16.3
windows 10

Cheers,
Yoan

[evanw]

Thanks for the report. I haven't encountered this issue before myself so it's good to have a report. It sounds like it only happens occasionally for you which will make this hard to debug.

I'll admit that, while esbuild supports Windows, I don't use Windows myself and I only test esbuild in a VM instead of on a native Windows machine. I wonder if there's a difference between running it in a VM vs. running native with regard to multithreading.

To round out the report, can you say how you are running this? Is this within WSL1 or WSL2 or is it in native Windows itself? Also, how often does this happen? Is it a rare 1 in 1000 run or is it 1 in 5? I'm asking because 1 in 5 would likely be much easier to debug. Also if you have any way of reproducing this that you could share with me, even if it only occasionally reproduces, I would be very interested.

Edit: I just ran 100 iterations of my benchmark through esbuild version 0.8.30 in my Windows 10 VM (no WSL) from the JavaScript buildSync API on a similar node version and they didn't hang. So I am unable to reproduce the issue given only this description.

[yoanthiebault]

To answer your questions:

• I am running it in native Windows
• It happens 1 in 5, sometimes 1 in 10. It's quite easy to reproduce on my setup.

Thank you for having tried to reproduce, it is still good to know that you could not reproduce on your side.
I didn't take time to investigate further as I found a workaround but maybe I could:

• check on Linux to be sure if it is related on Windows or not
• try to localize the issue with a debugger inside the js code as everything works fine when I directly use esbuild.exe

[evanw]

I'm going to close this because it's not currently actionable. Happy to reopen if more information is available. It's good to have a record of this in case it happens in the future in any case, so thanks for creating this issue.

[yoanthiebault]

Sure you’re right. FYI I tried on Linux and didn’t succeed to reproduce. Let’s reopen it if we get more information!

[kaksmet]

I suspect this issue is related to golang/go#36492

esbuild deadlocks about 1/10 of the time for me on my work laptop. It is running Windows 10 with Trend Micro anti-virus, which is consistent with the linked issue. It would also explain why you couldn't reproduce it inside a VM (which was probably not running an invasive anti-virus).

Setting the GODEBUG environment variable to asyncpreemptoff=1 has fixed this for me.

[yoanthiebault]

Awesome, thanks a lot for your post. Trend Micro is also installed on my work laptop, it's likely related. I will try your work-around.