Skip to content

libvips error messages are not safe to match on under concurrency #223

Description

@hlindset

because of libvips' background as a desktop library 1, libvips accumulates diagnostics in a process-global buffer, and when an operation fails Vix reads from that buffer. Under concurrency one thread can consume other threads' errors, while the other threads come out empty-handed. Any :reason derived from libvips is therefore unsafe to match on or in other ways rely on.

Evidence

Reproduction: open a malformed JPEG in a loop while 8 tasks open malformed TIFFs.

Contamination

22 of 300 consecutive identical calls returned a reason other than the expected one, e.g:

operation build: VipsJpeg: Invalid JPEG file structure: two SOI markers
source: bad seek to 2880154539
ctory
tiff2vips: Failed to read directory at offset 2880154539
vips__tiff_openin_source: unable to open source for input

The ctory fragment is a torn read, caused by Vix reading the buffer unlocked. PR for that opened here: akash-akya/vix#220

Loss

Whichever thread reads the buffer first consumes it, so an error can arrive with no message of its own. Same JPEG failure, with and without 8 tasks failing TIFF loads alongside it:

sequential:  JPEG errors missing their own message:  0/200
concurrent:  JPEG errors missing their own message: 24/300
sample reason: "operation build:"

24 of 300 reported operation build: and nothing else. The VipsJpeg: Invalid JPEG file structure line had gone into an unrelated TIFF operation's error.

This is a known problem in libvips, currently tracked here: libvips/libvips#5010.

Footnotes

  1. https://github.com/libvips/libvips/discussions/5009#discussioncomment-16685351

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions