Bug#1020802: libz3-4: Xorg crashes on startup due to illegal instruction (SSE2) in libz3-4

[Russ Dill]

On Tue, Oct 11, 2022 at 4:06 AM karogyoker999 <karogyoker2 at gmail.com> wrote:
>
> > As far as I see your MR just adds a dependency to sse2-support,
> > which I guess just makes the installation abort in case of a CPU
> > not supporting sse2, so I guess this would just make
> > mesa not installable on your hardware?
>
> Exactly.
>
> It will abort the installation as it wouldn't work anyways.
> Mesa now requires SSE2 and therefore Xorg as well.
> The workaround is to use Wayland with GNOME or KDE.
> But KDE requires SSE2 since several months too (and therefore fails to install).
> It is better to have the installation fail rather than
> having an unusable system after install. Because in the latter case,
> it would mean that users would be disappointed, much time would be wasted
> to troubleshoot. Failing the installation with a clear error message
> is a much better solution.

This is a bit of a further pain point for those out there running on
P6 systems as they commonly have video hardware that only supports
DRI1.

> The alternative would be to disable SSE2 for all i386 packages of libz3-4.
> But usually maintainers don't like that since that would have a performance
> impact on Pentium 4 CPUs. So there is a choice to make: disable SSE2 on
> all x86_32 CPUs or fail the install on everything except Pentium 4.

According to the developers of libz4-3, the precision of the FPU x87
registers is not sufficient therefore a libz4-3 package compiled
without SSE2 would be non-functional. It would be far better if
libz3-4 could fail late rather than early. If it could fail later, in
the case that calls to libz3-4 were made I think that would avoid the
current issue. Perhaps if video hardware that requires shader
compilation isn't present, no failures would occur. However the crash
occurs at dlopen time as there are a number of c++ static initializers
that get executed so even if no calls to libz3-4 are even made, or
even calls to the mesa library that links to libllvm14, which links to
libz3-4, everything works fine.

I'm not even certain that libz3-4 is ever even called by mesa. I think
it's just an option feature of libllvm and because mesa links libllvm,
it ends up calling dlopen on the libz3-4 library. The debian changelog
reads:

  * Enable Z3 solver (llvm & clang) to improve the quality of the static
    analysis results

This doesn't sound like a feature mesa needs and I can't find any
mention of mesa using the z3 solver.

> There is a Debian patch [1] for the z3 package which does something with SSE2.
> But then why is it still crashing? Maybe z3 has some hardcoded SSE2
> instruction somewhere?
> Or it has been just compiled with the incorrect compiler flags?

Doesn't appear to be disabling SSE2, just trying to make something
work when SSE2 is disabled. Not sure why.

> To have both performance and compatibility, a runtime check would be needed
> to be added, but that would mean a significant amount of work.
>
> Until this work is not done by someone, failing the installation is
> still better than
> crashing and leaving the system in an unbootable state.
>
> [1]: https://sources.debian.org/patches/z3/4.8.12-1/00-intrinsics.patch/

The package pulling in libz3-4 into the dependency chain is libllvm14.
I've noticed the ubuntu version of the package does not link against
libz3-4 and the libz3-4 package can be removed from the system and
xorg and mesa function just fine. Perhaps a version of libllvm14
compiled without libz3-4 support that could be installed on instead or
even along side?