Node.JS bindings Worker threads segfault reproduction #510
Conversation
Codecov Report
@@ Coverage Diff @@
## master #510 +/- ##
=======================================
Coverage 83.16% 83.16%
=======================================
Files 25 25
Lines 6678 6678
=======================================
Hits 5554 5554
Misses 1071 1071
Partials 53 53 Continue to review full report at Codecov.
|
|
Thanks for the test case, it segfaults here too. I'll look into finding the root cause |
|
Been trying to use https://www.npmjs.com/package/segfault-handler but it requires the |
|
Update, running the following script of CommonJS also generates the segmentation fault: const { Worker, isMainThread, workerData, parentPort } = require('node:worker_threads');
if (isMainThread) {
let input = "<html><span style=\"color:#ff0000;\">A phrase</span>";
const worker = new Worker(new URL('file:///home/taco/go/src/github.com/tdewolff/minify/bindings/js/test/worker.js'), {
workerData: input,
});
let expected = "<html><span style=color:red>A phrase</span>";
let output = new Promise((resolve, reject) => {
worker.on('message', resolve);
worker.on('error', reject);
worker.on('exit', (code) => {
if (code !== 0)
reject(new Error(`Worker stopped with exit code ${code}`));
});
})
} else {
const { string } = require('@tdewolff/minify');
string("text/html", workerData);
}However, using the segfault-handler as mentioned above, the segmentation fault is not caught! :-S |
|
I've found it, I had to add a clean up hook and call |
|
Thanks!!! This is working perfectly here: dotcore64/rollup-plugin-tdewolff-minify#7 |
|
Ah just need to update minify/bindings/js/package.json Line 3 in 2eed2f6 2.12.0 to deploy to npm :)
|
|
That ought to happen automatically in the Makefile that we invoke from the workflow. Just now I'm running the build script: https://github.com/tdewolff/minify/actions/runs/2645307256 |
|
Dammit this is actually not a good solution, https://github.com/dotcore64/rollup-plugin-tdewolff-minify/runs/7272307346?check_suite_focus=true |
I added a minimal test that reproduces the segfault issue. Unfortunately using the global stack didn't fix the issue
I'm afraid that maybe the go runtime might have internal resources that cannot be cleaned, in which case this issue could maybe not ever be solved? Really hope not...
Now, I also noticed if the module is loaded in both the main thread and in the worker thread, the application does not segfault and the tests pass beautifully (i.e, instead of
const { config, string } = await import('@tdewolff/minify'), doimport { config, string } from '@tdewolff/minify')