Bus error (webpack) when building Gitea

[bagasme]

Description

Hi,

I'm trying to build Gitea on commit 4bb1fcd, following build instructions. Node.js used is v18.19.0.

As I run make, the build stopped on webpack where webpack core dumped due to bus error (AFAIK, it because my Intel core i3 haswell processor can't attempt memory requests from node).

After examining the dump info (via coredumpctl info), it turns out that lightningcss module causes the webpack error.

This build issue is also reproduced on node v20.11.0.

Gitea Version

commit 4bb1fcd

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

https://gist.github.com/bagasme/d58a38beac308a20aa3b40dda2285021

Screenshots

n/a

Git Version

n/a

Operating System

Arch Linux

How are you running Gitea?

Building from source (node v18.19.0, go 1.21.6).

npx webpack info output:

  System:
    OS: Linux 6.8 Arch Linux
    CPU: (4) x64 Intel(R) Core(TM) i3-4030U CPU @ 1.90GHz
    Memory: 1.31 GB / 3.73 GB
  Binaries:
    Node: 18.19.0 - ~/.nvm/versions/node/v18.19.0/bin/node
    npm: 10.2.3 - ~/.nvm/versions/node/v18.19.0/bin/npm
  Packages:
    add-asset-webpack-plugin: 2.0.1 => 2.0.1 
    css-loader: 6.10.0 => 6.10.0 
    esbuild-loader: 4.0.3 => 4.0.3 
    license-checker-webpack-plugin: 0.2.1 => 0.2.1 
    lightningcss-loader: 2.1.0 => 2.1.0 
    monaco-editor-webpack-plugin: 7.1.0 => 7.1.0 
    vue-loader: 17.4.2 => 17.4.2 
    webpack: 5.90.1 => 5.90.1 
    webpack-cli: 5.1.4 => 5.1.4 

Database

None

[wxiaoguang]

I guess it is a upstream problem (as you mentioned: lightningcss), so Gitea could do nothing IMO?

Could you report the problem to upstream?

[silverwind]

The intention is that it should fall back to esbuild in case lightningcss crashes, but it appears we only catch startup crashes, not runtime crashes:

gitea/webpack.config.js

Lines 58 to 62 in 6992ef9

	// in case lightningcss fails to load, fall back to esbuild for css minify
	let LightningCssMinifyPlugin;
	try {
	({LightningCssMinifyPlugin} = await import('lightningcss-loader'));
	} catch {}

We could also just remove lightningcss if this turns out to be not fixable from our end. It will give slightly larger CSS files, but esbuild is arguably much more battle-tested.

[silverwind]

@bagasme Can you try if this changes anything?

NODE_OPTIONS="--max-old-space-size=4096" make webpack

This is more memory than your system has but I assume you have a swap file.

[bagasme]

@bagasme Can you try if this changes anything?

NODE_OPTIONS="--max-old-space-size=4096" make webpack

This is more memory than your system has but I assume you have a swap file.

Nope. I can still reproduce the webpack bus error.

[silverwind]

Hmm, so I guess your system may have too little memory for lightningcss to run. Do you have a swap file, and if not, create one? I would recomment at least 8GB size.

[bagasme]

I guess it is a upstream problem (as you mentioned: lightningcss), so Gitea could do nothing IMO?

Could you report the problem to upstream?

Done at parcel-bundler/lightningcss#671.

[bagasme]

Hmm, so I guess your system may have too little memory for lightningcss to run. Do you have a swap file, and if not, create one? I would recomment at least 8GB size.

Yes, I have 4GB RAM + 4.41GiB swap.

[silverwind]

Thanks, so let's see what comes out of the issue. I'm still leaning towards removing lightningcss, it just seems not stable enough.

[silverwind]

@bagasme can you try this patch on the affected machine?

diff --git a/webpack.config.js b/webpack.config.js
index c4b140a12b..16afa0ff9c 100644
--- a/webpack.config.js
+++ b/webpack.config.js
@@ -54,14 +54,8 @@ const filterCssImport = (url, ...args) => {

   return true;
 };

-// in case lightningcss fails to load, fall back to esbuild for css minify
-let LightningCssMinifyPlugin;
-try {
-  ({LightningCssMinifyPlugin} = await import('lightningcss-loader'));
-} catch {}
-
 /** @type {import("webpack").Configuration} */
 export default {
   mode: isProduction ? 'production' : 'development',
   entry: {
@@ -105,14 +99,11 @@ export default {
     minimizer: [
       new EsbuildPlugin({
         target: 'es2020',
         minify: true,
-        css: !LightningCssMinifyPlugin,
+        css: true,
         legalComments: 'none',
       }),
-      LightningCssMinifyPlugin && new LightningCssMinifyPlugin({
-        sourceMap: sourceMaps === 'true',
-      }),
     ],
     splitChunks: {
       chunks: 'async',
       name: (_, chunks) => chunks.map((item) => item.name).join('-'),

[bagasme]

@bagasme can you try this patch on the affected machine?

diff --git a/webpack.config.js b/webpack.config.js
index c4b140a12b..16afa0ff9c 100644
--- a/webpack.config.js
+++ b/webpack.config.js
@@ -54,14 +54,8 @@ const filterCssImport = (url, ...args) => {

   return true;
 };

-// in case lightningcss fails to load, fall back to esbuild for css minify
-let LightningCssMinifyPlugin;
-try {
-  ({LightningCssMinifyPlugin} = await import('lightningcss-loader'));
-} catch {}
-
 /** @type {import("webpack").Configuration} */
 export default {
   mode: isProduction ? 'production' : 'development',
   entry: {
@@ -105,14 +99,11 @@ export default {
     minimizer: [
       new EsbuildPlugin({
         target: 'es2020',
         minify: true,
-        css: !LightningCssMinifyPlugin,
+        css: true,
         legalComments: 'none',
       }),
-      LightningCssMinifyPlugin && new LightningCssMinifyPlugin({
-        sourceMap: sourceMaps === 'true',
-      }),
     ],
     splitChunks: {
       chunks: 'async',
       name: (_, chunks) => chunks.map((item) => item.name).join('-'),

Webpack build passed (no errors).

[silverwind]

#29070 will fix it by removing lightningcss. We can reconsider once it becomes more stable.

[github-actions]

Automatically locked because of our CONTRIBUTING guidelines