https://bugs.winehq.org/show_bug.cgi?id=46471
--- Comment #12 from noabody@yahoo.com --- With that in mind we can build an abstract of the problem.
KeePassLibC64.dll uses SSSE3 encryption functions KeePassLibC32.dll doesn't use SSSE3 AMD K10 lacks SSSE3
But the program works on K10 in Win64 so we'll expand:
KeePassLibC64.dll uses SSSE3 encryption functions KeePassLibC32.dll doesn't use SSSE3 AMD K10 lacks SSSE3 KeePass.exe tries to use LibC64 and falls back to LibC32 if SSSE3 not found
Now we'll apply that to wine stable:
KeePassLibC64.dll uses SSSE3 encryption functions KeePassLibC32.dll doesn't use SSSE3 AMD K10 lacks SSSE3 KeePass.exe tries to use LibC64 KeePass.exe falls back to LibC32 because a wine stubbed API function is not available Encryption is handed off to gnutls Program executes normally
And to wine-devel/staging:
KeePassLibC64.dll uses SSSE3 encryption functions KeePassLibC32.dll doesn't use SSSE3 AMD K10 lacks SSSE3 KeePass.exe uses LibC64 because a wine stubbed API function is available Encryption is handed off to gnutls gnutls returns a divide by zero
What changed between wine stable and devel with no change in keepass? We can surmise that a previously stubbed encryption call is now implemented.
But it's a bug in gnutls, right, that is the mechanism that handles encryption? It should see the SSSE3 instruction request, recognize that the CPU lacks the instruction set, and fallback to a software only implementation.
That suggests that any given SSSE3 instruction has an identical software function to wrap to. Maybe there is. Maybe the version of gnutls in Ubuntu 18.04 currently lacks the code to wrap the function call properly.