[openssl-users] Unhandled exception at 0x005904dc (libeay32.dll) (Windows x86)
wsware at gmail.com
Tue Aug 23 13:56:41 UTC 2016
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
>> 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
>> 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
>> nmake -f ms\ntdll.mak
>> nmake -f ms\ntdll.mak install
> According to the following page
> 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
> 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.
Jakob! Thank you so much! That was the issue.I added /arch:IA32 to the
APP_CFLAG and LIB_CFLAG in ms\ntdll.mak and I was able to compile a new
build that works on the problem machine. Is it worth doing a bug report on
so they might add that to the build scripts? Without it it seems like the
whole OPENSSL_ia32cap system is broken.
Before I had found this answer I had also installed nasm so I didn't have
to do the no-asm. So My current build process is:
>From the "Developer Command Promt for VS2013"
perl Configure VC-WIN32 --prefix=C:\OpenSSL-VC-32-DLL
(Edit ms\ntdll.mak to add /arch:IA32 to the APP_CFLAG and LIB_CFLAG)
nmake -f ms\ntdll.mak
nmake -f ms\ntdll.mak install
Thank you Jakob and the OpenSSL mailing list for the quick answers!
- Scott Ware
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the openssl-users