Bug#973414: libmozjs-78-0: invalid opcodes in libmozjs when launching GDM3

[Simon McVittie]

Control: tags -1 + moreinfo

On Fri, 30 Oct 2020 at 10:35:21 +0200, Martin-Éric Racine wrote:
> [  165.903916] traps: gnome-shell[869] trap invalid opcode ip:b5518f8a sp:b17d6d80 error:0 in libmozjs-78.so.78.3.0[b4b98000+98c000]

Which specific x86 CPU is this? I see `uname -m` is i586 rather than the
expected i686 (and there's only one core), so presumably it's somewhere
close to our architecture baseline, either above or below.  The baseline
is -march=i686 since gcc-6_6.1.1-1 and stretch, according to the research
I did for <https://wiki.debian.org/ArchitectureSpecificsMemo>.

The /proc/cpuinfo would be useful information, since that includes a list
of capability flags.

cc gcc maintainers (in the absence of an i386 porter contact): Is there
a more formal/detailed specification for what CPU extensions we do and
don't intend to require on i386?

If this CPU is at or slightly above the baseline and mozjs78 is using
non-baseline instructions, then that's a bug in the mozjs78 source (most
likely the JIT) or the packaging. If this is the case, I suspect that our
upstream (Mozilla) will refuse to support older CPUs, so we will have to
choose between making non-upstreamable changes or declaring that mozjs78
violating the baseline is wontfix. Our i386 mozjs78 is already built in a
configuration that upstream don't support, because they assume SSE on i386,
but SSE isn't part of our baseline, so we are still using the legacy i387
FPU instructions and their weird extended-precision behaviour; some tests
fail and are skipped as a result.

If it's slightly below the baseline (only a few missing opcodes), then it
isn't a bug for packages to not work, but it's possible that you get away
with it most of the time because the missing opcodes are rarely emitted?

Does Firefox work on this machine?

Did older versions of GNOME Shell (buster or stretch) work on this machine?
If yes, do they have acceptable performance in practice?

> [  204.840919] traps: gnome-session-f[939] trap invalid opcode ip:b4e7f86a sp:bfcc1460 error:0 in librsvg-2.so.2.47.0[b4e6d000+5b7000]

If this is considered a mozjs78 bug, then librsvg has a similar bug
(possibly related to Rust, which they both use); or if your CPU is just
too old to run binaries compiled with Debian's post-stretch assumptions,
then the same applies to librsvg.

librsvg is likely to be more of a problem than mozjs78, because you can
take mozjs78 out of the critical path by using XFCE, LXDE or one of the
GNOME 2 forks like MATE and GNOME Flashback, but if this is a desktop
system you are still going to want to render SVGs.

    smcv