https://bugs.winehq.org/show_bug.cgi?id=46471
--- Comment #9 from noabody@yahoo.com --- Based on the input from this report, my understanding is that gnutls/nettle have optimized encryption routines for various CPU instruction sets. Normally these would fallback based on what the processor can handle.
My belief is that, when keepass2 was compiled, its internal encryption libraries homed to the instruction set on the machine upon which it was built. This then would cause a flow-through where it had SIMD SSSE3 optimized gnutls requests which can't fallback because they're called explicitly.
It just flows from keepass2 through dotnet472 and wine bcrypt to nettle/gnutls/gmp/hogweed. The division by zero happens when the instruction set cannot be utilized. There's probably an interaction in there that could be addressed by wine but, ultimately, appears to be a fault in keepass2 itself.
I'll have to build locally on a non-K10 to see if keepass2, built by linux mono, still exposes the SIMD instructions whose resultant exe will fail on K10.