sharp icon indicating copy to clipboard operation
sharp copied to clipboard

SVG: Attempting to render <text> element without any fonts installed triggers segfault

Open jbrazeau opened this issue 9 months ago • 8 comments

Possible bug

Is this a possible bug in a feature of sharp, unrelated to installation?

  • [x] Running npm install sharp completes without error.
  • [x] Running node -e "require('sharp')" completes without error.

Are you using the latest version of sharp?

  • [x] I am using the latest version of sharp as reported by npm view sharp dist-tags.latest.

If you cannot confirm this, please upgrade to the latest version and try again before opening an issue.

If you are using another package which depends on a version of sharp that is not the latest, please open an issue against that package instead.

What is the output of running npx envinfo --binaries --system --npmPackages=sharp --npmGlobalPackages=sharp?

  System:
    OS: Linux 6.10 Alpine Linux
    CPU: (8) arm64 unknown
    Memory: 7.11 GB / 7.75 GB
    Container: Yes
    Shell: 1.36.1 - /bin/ash
  Binaries:
    Node: 20.11.1 - /usr/local/bin/node
    Yarn: 1.22.19 - /usr/local/bin/yarn
    npm: 10.2.4 - /usr/local/bin/npm
  npmPackages:
    sharp: 0.34.1 => 0.34.1 

Does this problem relate to file caching?

The default behaviour of libvips is to cache input files, which can lead to EBUSY or EPERM errors on Windows. Use sharp.cache(false) to switch this feature off.

  • [x] Adding sharp.cache(false) does not fix this problem.

Does this problem relate to images appearing to have been rotated by 90 degrees?

Images that contain EXIF Orientation metadata are not auto-oriented. By default, EXIF metadata is removed.

  • To auto-orient pixel values use the parameter-less rotate() operation.

  • To retain EXIF Orientation use keepExif().

  • [x] Using rotate() or keepExif() does not fix this problem.

What are the steps to reproduce?

The problem has been isolated in the following git project : https://gitlab.com/jean-francois.brazeau/bug-sharp

It simply converts 3 svg icons to PNG using sharp in a minimalist docker container.

  • Checkout https://gitlab.com/jean-francois.brazeau/bug-sharp
  • Open a terminal in the project
  • Run ./go.sh 0.33.5 (to see that there is no bug with 0.33.5)
  • Run ./go.sh 0.34.1 : a segmentation fault occurs when converting last SVG icon (among 3 provided SVG icons, the icon conversion that fails is the one associated to MARKDOWN_ICON icon, see src/icons.js file)

What is the expected behaviour?

We expect sharp 0.34.1 to behave like 0.33.5. In other words, we expect sharp 0.34.1 not to unexpectedly exit (generating a segmentation fault).

Using sharp 0.33.5 or above, the miniamist example outputs :

** convert svg icon: text
  text conversion done
** convert svg icon: pdf
  pdf conversion done
** convert svg icon: markdown
  markdown conversion done
** => Docker run completed successfully.

With 0.34.1, we get a segmentation fault :

** convert svg icon: text
  text conversion done
** convert svg icon: pdf
  pdf conversion done
** convert svg icon: markdown
Error: Docker run failed with exit code 139

Please provide a minimal, standalone code sample, without other dependencies, that demonstrates this problem

The problem has been isolated in the following minimalist project : https://gitlab.com/jean-francois.brazeau/bug-sharp

Please provide sample image(s) that help explain this problem

The sample image is provided in the minimalist project as SVG (see src/icons.js)

jbrazeau avatar Apr 14 '25 12:04 jbrazeau

My best guess would be that this has something to do with font discovery as the failing SVG contains a <text> element. Alpine Linux is minimal and does not include any fonts or font discovery helpers by default. Does it work if you add a font package such as font-noto (which should also add fontconfig as a dependency)?

https://sharp.pixelplumbing.com/install/#fonts

lovell avatar Apr 15 '25 08:04 lovell

Thank you very much for your response. You're perfectly right, the icon was badly rendered due to the missing font in the docker container (and I wonder why we didn't see that before !).

I don't know if the fact that now sharp abruptly exits in such a case is a problem or not, but on our side we'll simply add the missing font and we'll continue to test 0.34.1 version integration.

Thanks again.

jbrazeau avatar Apr 15 '25 10:04 jbrazeau

Thanks for the update, I'll keep this open as I'd like to investigate why the process is exiting to see if there's anything we can do to improve the experience.

lovell avatar Apr 20 '25 21:04 lovell

I've opened an upstream issue about this at https://gitlab.gnome.org/GNOME/librsvg/-/issues/1164

lovell avatar Apr 24 '25 16:04 lovell

Is it possible add a warning at the import time or before calling rsvg if system does not have /usr/share/fonts?

"WARNING: You are using unsupported configuration, which can lead to segfaults during svg image parsing"

gugu avatar May 17 '25 13:05 gugu

I've suggested a possible fix upstream - see https://gitlab.gnome.org/GNOME/librsvg/-/merge_requests/1106

lovell avatar May 18 '25 09:05 lovell

A possible workaround whilst we wait for the upstream fix is to block SVG rendering:

sharp.block({
  operation: ['VipsForeignLoadSvg']
});

https://sharp.pixelplumbing.com/api-utility/#block

lovell avatar Jun 05 '25 07:06 lovell

Release candidate v0.34.3-rc.0 is now available if you'd like to test the upstream fix.

lovell avatar Jun 14 '25 21:06 lovell

sharp v0.34.3 is now available with prebuilt binaries that include the upstream fix.

lovell avatar Jul 10 '25 08:07 lovell