Bug#1145932: freeze is in kimg_jxl/libjxl, not SnapBackend — please reopen and reassign

Subject: Bug#1145932: freeze is in kimg_jxl/libjxl, not SnapBackend —
please reopen and reassign

Control: reopen -1
Control: reassign -1 src:kf6-kimageformats

Hello,

I would like to add isolation data to this bug, which I believe was closed
in error.

The upload that closed it, plasma-discover 6.7.4-2, backports an upstream
commit for SnapBackend ("signal completion of update check with zero
upgradeable snaps"). That commit does not touch the PackageKit code path
described in the original report, so it cannot address the reported
symptom. Two people have already replied in this log stating the freeze
persists with 6.7.4-2.

I still have 6.7.4-1 installed, so I cannot personally confirm the
behaviour of -2; my data below is from -1. What I can contribute is a
reproducible isolation of the actual failing component.

ISOLATION (three steps, reversible)

1. Moving /usr/lib/x86_64-linux-gnu/qt6/plugins/imageformats/kimg_jxl.so
   out of the plugin directory: Discover starts and renders the Home page
   normally.
   (Renaming it in place is not sufficient - Qt's plugin loader reads the
   internal metadata regardless of file extension and loads it anyway.)

2. Restoring the plugin: Discover freezes again on Home, window title
   shows "(no responde)".

3. With the plugin restored and only one icon file removed from the
   AppStream catalogue, Discover starts and renders Home normally. That
   file is:

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

EVIDENCE DURING THE FREEZE

strace shows the file being opened immediately before the hang, and the
file descriptor remains open while the process is unresponsive:

  ls -l /proc/<pid>/fd | grep -i jxl
  lr-x------ 1 ... 75 ->
/var/lib/swcatalog/icons/debian-forky-main/64x64/scite_Sci48M.jxl

The main thread sits at 99% CPU in user space for as long as the window is
frozen, with State: R, wchan 0 and an empty /proc/<pid>/stack - i.e. a
loop inside userspace code, not a blocked syscall and not a deadlock on a
backend.

I am attaching the triggering file (scite_Sci48M.jxl, 7656 bytes, reported
by file(1) as a valid JPEG XL codestream).

RELATION TO THE UPSTREAM BUG

This looks like the same component as KDE bug 524885 (frameworks-
kimageformats), "kimg_jxl.so crashes (SIGABRT) when decoding certain JXL
images via QIcon::actualSize / QImageReader::jumpToNextImage":

  https://bugs.kde.org/show_bug.cgi?id=524885

One difference worth recording: upstream describes a SIGABRT, whereas both
the original report here and my system show a hang rather than a crash.
Same call path, different outcome, presumably depending on the particular
JXL file. The trigger also differs per system - abe_abe.jxl upstream,
video-downloader in the original report here, scite_Sci48M.jxl on mine -
which argues against a single corrupted file and for a systematic problem
with how libjxl 0.11.2 handles a class of these images.

In that upstream bug, Albert Astals Cid reports it working with
kimageformats 6.29.0 and libjxl 0.12.0. As far as I can tell, libjxl 0.12
is not packaged in Debian in any suite (src:jpeg-xl is at 0.11.2-5 in
unstable), so there is currently no upgrade path for users on testing.

VERSIONS

  plasma-discover         6.7.4-1
  kimageformat6-plugins   6.28.1-1+b1
  libjxl0.11              0.11.2-5.1
  appstream               1.1.6-1
  Qt                      6.10.2
  Architecture            amd64

Disclosure: I run Soplos Linux, a derivative of Debian testing (forky).
The packages involved here are unmodified Debian packages from
deb.debian.org forky/main, with no local patches, diversions or pinning
applied to plasma-discover, kimageformat6-plugins, libjxl or appstream.

Given the above I would suggest this belongs to src:kf6-kimageformats or
src:jpeg-xl rather than src:plasma-discover; I have set a reassign control
command to the former, please redirect it if you judge otherwise.

Happy to run any further tests on request.

Regards,
Sergi Perich
Soplos Linux