> The 32-bit of openSSL 1.0.0a (solaris-sparcv9-cc configuration)
> coredumps upon initialization. The stack trace is (of our product
> binary):
Does reference to your product binary mean that apps/openssl does not
crash? In other words does 'make test' pass? If so, then the question is
how come? Try to truss your application and compare it to truss output
for 'apps/openssl version'... Try to single-step your application in
debugger...
> #0 0xff360c90 in free_unlocked () from /usr/lib/libmalloc.so.1
> #1 0xff360b78 in free () from /usr/lib/libmalloc.so.1
> #2 0x007107a4 in OPENSSL_cpuid_setup ()
> #3 0x00791784 in ?? ()
> #4 0x00791784 in ?? ()
Note that OPENSSL_cpuid_setup does not call free() (see
crypto/sparcv9cap.c). It does call dlopen("libdevinfo.so.1",RTLD_LAZY)
and dlclose(h) though... As well as some functions from libdevinfo... I
mean chances are that root of the problem lies outside
OPENSSL_cpuid_setup... It's easy to verify by setting OPENSSL_sparcv9cap
environment variable (value of 3 is appropriate for USII) prior starting
your application.
But the key question is of course what to do about it. I'd suggest to
start by checking if Sun has any libdevnfo patches. Then we'll have to
see on feedback you provide...
> A Sun Enterprise 450 is a system with a Ultra-SparcII processore. For
> some reason, this crash appears in OpenSSL 1.0.0a, but did not in
> OpenSSL 0.9.8k
Above mentioned sparcv9cap.c is new in 1.0.0. A.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
