[openssl-users] Unhandled exception at 0x005904dc (libeay32.dll) (Windows x86)

[Thomas J. Hruska]

On 8/25/2016 9:21 PM, Jakob Bohm wrote:
> On 26/08/2016 05:42, Scott Ware wrote:
>> On Mon, Aug 22, 2016 at 8:05 PM, Jakob Bohm <jb-openssl at wisemo.com>
>> wrote:
>>> On 22/08/2016 22:33, Scott Ware wrote:
>>>> On Mon, Aug 22, 2016 at 3:04 PM, Jakob Bohm <jb-openssl at wisemo.com
>>>> <mailto:jb-openssl at wisemo.com>>wrote: On 22/08/2016 20:09, Scott
>>>> Ware wrote: We use libeay32.dll and ssleay32.dll from
>>>> https://slproweb.com/products/Win32OpenSSL.htmlin
>>>> <https://slproweb.com/products/Win32OpenSSL.htmlin>our applications
>>>> and we recently moved from version 1.0.2a to 1.0.2g and now on a few
>>>> machines running a AMD Geode processor we are getting "Unhandled
>>>> exception at 0x005904dc (libeay32.dll) in Test.exe: 0xC000001D:
>>>> Illegal Instruction". We ended up building OpennSSL so we could
>>>> debug into it and found it is failing on "movsd xmm0,mmword" (see
>>>> below) which the AMD Geode does not seem to support. I have tried
>>>> "SET OPENSSL_ia32cap=~0x1000000", "SET OPENSSL_ia32cap=~0x2000000",
>>>> and "SET OPENSSL_ia32cap=~0x7000000"; and nothing seems to change. I
>>>> may not be using OPENSSL_ia32cap correctly. This happens when
>>>> calling SSL_CTX_new which then calls RAND_add. Any ideas on the best
>>>> thing to do? We don't want to have to manage different compiled
>>>> versions of libeay32.dll and ssleay32.dll if we can help it. Your
>>>> disassembly looks like the C compiler was invoked with options that
>>>> caused regular C floating point code (in this case, the passing of
>>>> 45.0 as an argument to RAND_add()) to be compiled into MMX/SSE
>>>> instructions instead of backwards compatible 80x87 floating point
>>>> instructions or (for simple cases like this) regular integer unit
>>>> data movement instructions (such as two pushes of 32 bit constants
>>>> that contain the halves of the 64 bit double constant, which would
>>>> have been more efficient on every x86 CPU). Did the build scripts or
>>>> other source code contain any differences from the official source
>>>> code that can be downloaded from openssl.org <http://openssl.org>?
>>>> How did you invoke the build scripts (command sequence, special
>>>> build environment, special environment variables etc.)? Which
>>>> compiler and compiler version/edition did you use? It would be
>>>> interesting to know if one of the common Windows compilers does this
>>>> unconditionally, making it unsuitable for use in programs that need
>>>> to be backwards compatible. I compiled using this process and seem
>>>> to be getting the same result as the .dll I downloaded from
>>>> slproweb.com <http://slproweb.com> I downloaded the 1.0.2g source
>>>> from openssl.com <http://openssl.com>and didn't change anything.
>>>> From the "Developer Command Promt for VS2013" perl Configure
>>>> debug-VC-WIN32 no-asm --prefix=C:\OpenSSL-VC-32-dbg ms\do_ms nmake
>>>> -f ms\ntdll.mak nmake -f ms\ntdll.mak install
>>> According to the following page
>>> https://msdn.microsoft.com/en-us/library/7t5yh4fd%28v=vs.120%29.aspx
>>> Visual Studio 2012 and later requires the following compiler option
>>> to generate code compatible with older CPUs (this is the default in
>>> Visual Studio 2010, and VS2010 does not support the option):
>>> /arch:IA32 This compiler gotcha is specific to the 32 bit x86
>>> architecture, the default looks like it is still sane for x86_64.
>>> Note to the FIPS team: Please check if this affects the FIPS module
>>> building procedure.
>> Well, I tried to get my normal distribution source to compile with
>> /arch:IA32. Didn't go well. :( On Thu, Aug 25, 2016 at 10:12 PM,
>> Thomas J. Hruska <shinelight at shininglightpro.com> wrote:
>>> On 8/23/2016 7:19 AM, Scott Ware wrote:
>>>> Shining Light Productions, Would you consider implementing this in
>>>> your builds? VS2012 and above require the /arch:IA32 flag to produce
>>>> x86 code compatible with older CPUs.
>>>> https://mta.openssl.org/pipermail/openssl-users/2016-August/004260.html
>>>> Thanks, Scott Ware

>>> This is an upstream issue. I only do default builds. Contact the
>>> OpenSSL developers if you want that flag added to the default build
>>> process. SSE2 is the default target architecture for Visual Studio
>>> when /arch is not specified. If you don't have a CPU with SSE2
>>> instruction support, then it is long past due for a hardware upgrade.

> Bad on them, those of us that have seen this kind of hardware
> all know that Geode CPUs use very very little power compared
> to modern Intel CPUs, less even than most of Intel's "Atom"
> CPUs.

Then push a request upstream to change the default build settings. 
Don't blame me.  The binaries that are built are built strictly with 
default settings with the only exception being the various funky runtime 
linker options (/MD, /MT, etc).  If you don't like the defaults, then 
get the upstream changed.

-- 
Thomas Hruska
Shining Light Productions

Home of BMP2AVI and Win32 OpenSSL.
http://www.slproweb.com/