Linux-x64 builds lead to crashing / core dump due to SSE4.1 instructions being present on older x86_64 machines

[gokberkkocak]

On a dotnet application - ie. jellyfin - we run on relatively old hardware, we are experiencing core dumps and crashes due to trap invalid opcode on libe_sqlite3.so.

[1963502.669640] traps: .NET TP Worker[512340] trap invalid opcode ip:7f5d7f90edfa sp:7f5d74747ce0 error:0 in libe_sqlite3.so[38dfa,7f5d7f8e7000+d9000]

Investigating the issue on jellyfin/jellyfin#15148, we have found out that, SQLitePCL.raw provided builds of libe_sqlite3.so are optimised towards x86_64-v2+ due to including instructions such blendvpd which is part of SSE4.1. This leads to the core dump via trap invalid opcode on hardware does not aware of said instruction.

As a result, this breaks this library's usage on older x86_64 systems that not support SSE4.1.

As an example data point - the CPU on my headless setup is Intel(R) Atom(TM) N2800 and does not provide SSE4.1 instructions:

ie.

$ cat /proc/cpuinfo | grep sse4_1

no result.

We suspect that your current build system enables this extra set of instructions meanwhile linux distributions provided sqlite3 / libsqlite3.so does not enable these to not break x86_64 compatibility.

We encountered this issue in v2.1.11 (might be present earlier) and it still present on later v3 versions as well.

Example to verify existence of said instructions:

wget https://www.nuget.org/api/v2/package/SQLitePCLRaw.lib.e_sqlite3/2.1.11
unzip 2.1.11
objdump -d runtimes/linux-x64/native/libe_sqlite3.so  | grep blendvpd

   23d1c:	66 0f 38 15 ca       	blendvpd %xmm0,%xmm2,%xmm1
   ...

Recent SourceGear builds:

wget https://www.nuget.org/api/v2/package/SourceGear.sqlite3/3.50.4.2
unzip 3.50.4.2
objdump -d ./runtimes/linux-x64/native/libe_sqlite3.so | grep blendvpd

    26ece:	66 0f 38 15 ca       	blendvpd %xmm0,%xmm2,%xmm1
    ...

I believe it is important to keep x86_64 backwards compatibility on any hardware and if this library wants to benefit from SSE4.1 or any other additional instructions for performance or other reasons, it should provide x86_64-v2, x86_64-v3 etc. separately somehow.

[ericsink]

Thanks for the detailed report. I'll need to figure out what to do.

[Bond-009]

Looking into this I'm pretty sure this is the issue: https://github.com/ericsink/cb/blob/master/bld/cb.cs#L145
Introduced in this PR: ericsink/cb#19
Merged on the same day as Release 2.1.6 (which probably didn't contain that change and works fine)

Confirmed with the method posted by @gokberkkocak that 2.1.6 doesn't contain the blendvpd instruction, but 2.1.7 does.

[ahenriksson]

I'm hitting this issue as well. @Bond-009 thank you for finding the likely culprit! I believe the second link is supposed to be this one: ericsink/cb#19

Would it be possible to simply remove the -msse4.2 and -maes compiler flags introduced in that PR, if that is indeed the cause? For an x64 binary to just go ahead and execute these extension instructions without checking the CPU or providing a fallback path is, IMHO, somewhat impolite :-)

Using accelerated CPU instructions for cryptographic code when available is obviously a good thing, but I'm not sure if these flags are even necessary for that? Isn't that generally done with handwritten code using intrinsics, guarded by a CPU check, like in this file?: https://github.com/utelle/SQLite3MultipleCiphers/blob/main/src/aes_hardware.c

I suspect that these flags just cause the compiler to sprinkle unsupported instructions wherever it happens to find a use for them, with minimal performance benefits.