sharp: arm64, palette-based PNG input, Incorrect checksum for freed object

Possible bug

Randomly throws error

node(35349,0x170cab000) malloc: Incorrect checksum for freed object 0x114018800: probably modified after being freed.
Corrupt value: 0x709090907090909
node(35349,0x170cab000) malloc: *** set a breakpoint in malloc_error_break to debug

Or [1] 35277 segmentation fault node index.js

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

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

Are you using the latest version of sharp?

  • 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: macOS 12.3.1
    CPU: (10) arm64 Apple M1 Max
    Memory: 1.53 GB / 32.00 GB
    Shell: 5.8 - /bin/zsh
  Binaries:
    Node: 16.9.1 - ~/.nvm/versions/node/v16.9.1/bin/node
    Yarn: 1.22.18 - /opt/homebrew/Cellar/yvm/4.1.4/shim/yarn
    npm: 7.21.1 - ~/.nvm/versions/node/v16.9.1/bin/npm
    Watchman: 2022.03.21.00 - /opt/homebrew/bin/watchman
  npmPackages:
    sharp: ^0.30.4 => 0.30.4 
  npmGlobalPackages:
    sharp: 0.30.4

What are the steps to reproduce?

git clone https://github.com/headfire94/sharp-bug-report node index.js - few times

What is the expected behaviour?

generate compressed PNG

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Reactions: 1
  • Comments: 16 (8 by maintainers)

Commits related to this issue

Most upvoted comments

I think what we’re seeing here is an effect of #3225

The problem in this issue only occurs on CPUs that provide NEON (i.e. arm64), with some palette-based PNG inputs and always palette-based PNG output.

The use of palette-based output forces libvips to decompress the whole image into memory at once, rather than stream smaller regions, and I think this difference is just enough to trigger the (1 byte, I think) buffer overflow of #3225

The forthcoming v0.31.0 of sharp will provide prebuilt binaries that use the latest libspng with the fix. In the meantime, you might be able to workaround this by using brew install vips first, which should install libspng v0.7.2.

i can confirm that it still fails with

- .png({ compressionLevel: 9, quality: 90 })
+ .png({ palette: true })