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

[Scott Ware]

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.
>
> --
> Thomas Hruska
> Shining Light Productions
>
> Home of BMP2AVI and Win32 OpenSSL.
> http://www.slproweb.com/