wasm-vips is unstable on Node 18.14.2+ and 19.4.0+

[atjn]

Node has recently made a change to the WASM interpreter that is causing errors in wasm-vips. The errors seem completely random and affect many modules, but the most affected module seems to be libspng which cannot decode even a simple png file.

The issue was introduced in Node 18.14.2 and 19.4.0. I was not able to reproduce this error in the Chromium browser, version 110.0.5481.177 and 112.0.5615.20.
The issue does not affect wasm-vips version 0.0.4, although I am not sure when exactly the issue was "introduced". Maybe with the switch to Meson for libvips? I know for sure that b24ca0b and later is affected.
I hope this is not OS-specific, but FYI I have only run these tests on Ubuntu 22.04, on an Intel 10th-gen x64 chip.

I noticed the errors while working on EWAB, but the test suite also reports errors on these versions:

Full test suite report

1) colour
       cmyk:
     vips::Error: unable to call colourspace
vips__file_open_read: unable to open file "cmyk" for reading
unix error: No such file or directory
profile_load: unable to load profile "cmyk"

      at Wc (file:///home/anton/Documents/GitHub/wasm-vips/lib/vips-node.mjs:125:428)
      at wasm://wasm/0152235e:wasm-function[4260]:0x1ae91f
      at Nd.Image$colourspace (eval at Ge (file:///home/anton/Documents/GitHub/wasm-vips/lib/vips-node.mjs:162:242), <anonymous>:10:10)
      at a.<computed> [as colourspace] (file:///home/anton/Documents/GitHub/wasm-vips/lib/vips-node.mjs:152:259)
      at Context.<anonymous> (file:///home/anton/Documents/GitHub/wasm-vips/test/unit/test_colour.js:212:21)
      at process.processImmediate (node:internal/timers:475:21)

  2) connection
       image
         writeToTarget
           custom:

      AssertionError: expected 242 to equal +0
      + expected - actual

      -242
      +0
      
      at Context.<anonymous> (file:///home/anton/Documents/GitHub/wasm-vips/test/unit/test_connection.js:161:55)
      at process.processImmediate (node:internal/timers:475:21)

  3) foreign
       png:
     AssertionError: expected +0 to be close to 38671 +/- 0.0001
      at file:///home/anton/Documents/GitHub/wasm-vips/test/unit/helpers.js:181:33
      at Array.forEach (<anonymous>)
      at Module.assertAlmostEqualObjects (file:///home/anton/Documents/GitHub/wasm-vips/test/unit/helpers.js:180:19)
      at pngValid (file:///home/anton/Documents/GitHub/wasm-vips/test/unit/test_foreign.js:396:15)
      at fileLoader (file:///home/anton/Documents/GitHub/wasm-vips/test/unit/test_foreign.js:79:5)
      at Context.<anonymous> (file:///home/anton/Documents/GitHub/wasm-vips/test/unit/test_foreign.js:402:5)
      at process.processImmediate (node:internal/timers:475:21)

  4) foreign
       svgload:
     vips::Error: unable to load from file ./images/logo.svgz
VipsForeignLoad: "./images/logo.svgz" is not a known file format

      at Wc (file:///home/anton/Documents/GitHub/wasm-vips/lib/vips-node.mjs:125:428)
      at wasm://wasm/0152235e:wasm-function[1301]:0x7e5ec
      at Function.Image$newFromFile (eval at Ge (file:///home/anton/Documents/GitHub/wasm-vips/lib/vips-node.mjs:162:242), <anonymous>:8:10)
      at a.<computed> [as newFromFile] (file:///home/anton/Documents/GitHub/wasm-vips/lib/vips-node.mjs:152:259)
      at fileLoader (file:///home/anton/Documents/GitHub/wasm-vips/test/unit/test_foreign.js:80:21)
      at Context.<anonymous> (file:///home/anton/Documents/GitHub/wasm-vips/test/unit/test_foreign.js:883:5)
      at process.processImmediate (node:internal/timers:475:21)

  5) resample
       thumbnail:

      AssertionError: expected 48.23111979166666 to be below 1
      + expected - actual

      -48.23111979166666
      +1
      
      at Context.<anonymous> (file:///home/anton/Documents/GitHub/wasm-vips/test/unit/test_resample.js:268:82)
      at process.processImmediate (node:internal/timers:475:21)

Pending fixes:

• Commit a fix for 18.x - [v18.x] deps: V8: cherry-pick 9ec4e9095a25 nodejs/node#47092
• Released in 18.16.0 - https://github.com/nodejs/node/releases/tag/v18.16.0
• Commit a fix for 19.x - [v19.x] deps: V8: cherry-pick 9ec4e9095a25 nodejs/node#47535
• Released in 19.10.0 - https://github.com/nodejs/node/releases/tag/v19.10.0
• Fixed in 20+ by updating V8 - deps: update V8 to 11.3 nodejs/node#47251

[kleisauke]

I was aware of this and reported this a couple of weeks ago at nodejs/node#46446 (comment). Unfortunately, that particular v8 commit is not cherry-picked at the time of writing.

This issue manifests with zlib-ng (both with v2.0.6 and the upcoming v2.0.7) when decompressing a zlib stream via inflate(), which means that wasm-vips v0.0.4 is also affected. Fortunately, building zlib-ng from the develop branch somehow(?) doesn't reproduce this.

I just pushed commit 7f4de7a as a workaround, but a better fix would be for Node.js to cherry-pick that particular v8 commit, as this may affect other Wasm projects as well.

[atjn]

I see, thank you!
I will keep this bug open for tracking a more permanent fix :)

[kleisauke]

I just opened PR nodejs/node#47092 for this.

[atjn]

Haha, I am currently compiling Node with the patch applied, with the intent to create that PR. I guess I will spare my poor CPU.

[atjn]

I am guessing that you are already well into getting a [v19.x] PR ready as well, but let me know if you want me to do anything. After all, I do have the patch ready 😄

[kleisauke]

I had a PR ready for v19.x, but I wasn't sure if commits from v18.x are cherry-picked to v19.x and/or whether there was a plan to update V8 there. Both would make that possible PR redundant.

I just asked at nodejs/node#47092 (comment) if it's needed/appropriate to submit a PR for that.

[atjn]

I could be wrong, but I believe the common workflow is to commit the fix directly to main, from where it will automatically be included in a 19.x (maybe 20.x now) release, and then also commit it to every LTS release that is no longer coupled to main, in this case just v18.x-staging.

[kleisauke]

In that case, commit nodejs/node@f226350 would solve this as well. The corresponding PR of that commit does not have the dont-land-on-v19.x label, so hopefully that will be included in v19.x.

[kleisauke]

Node 18.16.0 has been released with a fix for this.

This issue still affects Node v19.x, I just opened PR nodejs/node#47535 for that (commit nodejs/node@f226350 was supposed to be included in the upcoming Node v20 release).

[kleisauke]

According to https://github.com/nodejs/release#end-of-life-releases Node v19.x has been EOLed, so I think v19.10.0 will not be released.

I'll close, thanks for reporting this!

[atjn]

It seems to me like they will release it at some point, but as you say, it really isn't important as long as all supported versions are fixed :)