Bug#1145932: ~/jxl-trigger-clamtk.jxl

Hello,

Follow-up with further data narrowing this down. Short version: libjxl
decodes the affected files correctly, so the fault appears to be specific
to the icon-engine path in kimageformats rather than to JPEG XL decoding
as such.

SECOND TRIGGER FILE

After removing the first trigger, Discover loaded Home but froze again on
the Installed view, on a different file:

  /var/lib/swcatalog/icons/debian-forky-main/64x64/clamtk_clamtk.jxl

Same signature as before: the file descriptor stays open while the process
is unresponsive at 99% CPU.

  ls -l /proc/22121/fd | grep -i jxl
  lr-x------ 1 ... 13 ->
/var/lib/swcatalog/icons/debian-forky-main/64x64/clamtk_clamtk.jxl

So there are at least four independent trigger files across three systems:
abe_abe.jxl (KDE 524885), video-downloader (this bug, original report),
scite_Sci48M.jxl and clamtk_clamtk.jxl (here). They come from unrelated
packages.

LIBJXL DECODES THEM FINE

djxl from libjxl-tools 0.11.2-5.1, i.e. the same libjxl the plugin links
against, decodes both of my trigger files without any problem:

  for f in scite_Sci48M.jxl clamtk_clamtk.jxl ark_ark.jxl; do
      timeout 10 djxl "$f" /tmp/out.png >/dev/null 2>&1; echo "$? $f"
  done
  0  scite_Sci48M.jxl     (freezes Discover)
  0  clamtk_clamtk.jxl    (freezes Discover)
  0  ark_ark.jxl          (renders fine in Discover)

Exit code 0 in all three cases - no hang, no error. jxlinfo also reads all
of them without issue.

Gwenview opens clamtk_clamtk.jxl and displays it correctly as well.

HEADERS ARE IDENTICAL BETWEEN WORKING AND FAILING FILES

jxlinfo output is byte-for-byte the same description for both the files
that freeze Discover and the ones that render fine:

  JPEG XL image, 64x64, (possibly) lossless, 8-bit RGB+Alpha
  Color space: RGB, D65, sRGB primaries, sRGB transfer function,
  rendering intent: Relative

So dimensions, bit depth, alpha and colour profile do not distinguish the
failing files from the working ones. I also checked whether the trigger
files were ones missing some of the 48x48/64x64/128x128 variants in the
catalogue; several hundred icons are incomplete in that way and most of
them render fine, and video-downloader (the trigger in the original
report) has all three sizes, so that is not the discriminator either.

WHAT THIS POINTS AT

Given that libjxl decodes these files correctly on its own, and Gwenview
displays them correctly, but Discover hangs on them via

  kimg_jxl.so
  QImageReader::size()
  QPixmapIconEngine::bestMatch()
  QPixmapIconEngine::actualSize()
  QIcon::actualSize()
  libKirigamiPrimitives

the problem looks specific to how the plugin behaves when driven from the
icon engine path (size query / bestMatch iteration), not to JXL decoding
in general. That is consistent with the reassignment to
src:kf6-kimageformats rather than src:jpeg-xl.

I am attaching the second trigger file (clamtk_clamtk.jxl, 5061 bytes).
The first one (scite_Sci48M.jxl) is attached to my previous message.

Versions unchanged from my previous message: kimageformat6-plugins
6.28.1-1+b1, libjxl0.11 0.11.2-5.1, Qt 6.10.2, amd64.

Happy to run anything else that would help.

Regards,
Sergi Perich
Soplos Linux