On 2024-02-29 12:34:17 +0100, Vincent Lefevre wrote: > Indeed, this was caused by the upgrade of the pango library. I've > just posted on the upstream bug: > > Actually, the problem also occurs with gnuplot 5. It has actually > appeared with the 1.52 pango library: downgrading the pango packages > to 1.51 makes the problem disappear, both with gnuplot 5 and 6. Now, > I don't know whether this is a bug in pango or a bug in gnuplot that > is triggered only with the new version of pango (for instance, it > might be possible that pango 1.52 is faster than 1.51, making the > problem appear, since it seems to be a race condition).
I've identified the "problematic" commit in Pango, and I would tend to say that this is the reason: https://gitlab.gnome.org/GNOME/pango/-/commit/89442dae443eba2aa0f0a526b4d6d39c0c9b13c6 According to the commit message, a new thread was created "for every single fontconfig call". Now "a single fontconfig thread per fontmap" is used. So I suppose that this makes Pango faster, triggering the race condition in gnuplot. I've updated the upstream gnuplot bug and opened a bug in Pango, hoping confirmation: https://gitlab.gnome.org/GNOME/pango/-/issues/784 -- Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
