[Pkg-kde-extras] Bug#993760: libexiv2-27:i386: non-baseline instructions cause crash on AMD Geode

[Martin-Éric Racine]

ma 6. syysk. 2021 klo 11.37 Simon McVittie (smcv at debian.org) kirjoitti:
>
> Control: retitle -1 libexiv2-27:i386: non-baseline instructions cause SIGILL on AMD Geode
> Control: reassign -1 libexiv2-27
> Control: affects -1 + tracker-extract
> Control: tags -1 + moreinfo
>
> On Mon, 06 Sep 2021 at 09:48:00 +0300, Martin-Éric Racine wrote:
> >        Message: Process 838 (tracker-extract) of user 1000 dumped core.
> >
> >                 Stack trace of thread 838:
> >                 #0  0x00000000b1009f90 n/a (libexiv2.so.27 + 0x74f90)
>
> This looks to me like it's libexiv2.so.27 that is crashing, with an
> illegal instruction (SIGILL). You're using an AMD Geode, which is
> very close to the minimum for Debian's i386 baseline, so non-baseline
> instructions are likely to be found there first.
>
> What version of libexiv2-27 is installed? Unfortunately reportbug
> only lists version numbers for direct dependencies, and tracker-extract
> uses libexiv2-27 via libgexiv2-2 rather than directly.

$ dpkg -l | grep exiv
ii  libexiv2-27:i386                     0.27.3-3+deb11u1
 i386         EXIF/IPTC/XMP metadata manipulation library
ii  libgexiv2-2:i386                     0.12.1-1
 i386         GObject-based wrapper around the Exiv2 library

> > (gdb) x/16i $pc
> > => 0xb1009f90:        endbr32
>
> If I remember correctly, endbr32 is a CET opcode (a repurposed "long NOP")
> that is supported on most i686-class CPUs, but notably is considered an
> illegal instruction on Geode. This seems most likely to be something
> to do with how libexiv2-27 was compiled, rather than the libexiv2-27
> source code.
>
> If libexiv2-27 had been rebuilt in unstable recently then I would be saying
> this is probably fallout from gcc-11 briefly having enabled CET on i386
> (#993162, #993172), but it hasn't - unless you have rebuilt it locally?

I haven't rebuilt it. The host had whatever the repository offers.

> It look as though tracker-extract is inspecting some file in "raw" format.
> Can you find out (perhaps from /proc/$PID/fd) which file, and try running
> the exiv2 tool against it? If that crashes too, then this is certainly not
> a tracker bug.

I wouldn't even begin to know how to manually run tracker-extract in
verbose mode to produce the info.

Martin-Éric