Hi, > -----Original Message----- > From: Andy Polyakov via RT [mailto:r...@openssl.org] > Sent: Saturday, 21 August, 2010 14:42 > To: Kees Dekker > Cc: openssl-dev@openssl.org > Subject: Re: [openssl.org #2321] bug report: core dump on > OPENSSL_cpuid_setup() on Solaris 10 with a Sun Enterprise 450 system > > > 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...
The openSSL and cURL libs are built on a different system (e.g. Sun Fire V440
or Sun Fire T200). This (old) system
being used, where the crash occurs, is a test system, and not equiped with a
compiler (similar
to customer situation). So (re)building on this test system, or run make test
is not possible.
>
> > #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.
I saw that no free was called (I did check the source code as well), but Using
OPENSSL_sparcv9cap=3 works well.
But skipping the dlopen by setting OPENSSL_sparcv9cap environment variable
solved the problem... So I'm not 100% sure that the problem is outside
OPENSSL_cpui_setup(). But I also can't explain why this problem did not exist
on our other/newer (V440/T200) systems. These two are not Ultra-sparcII, but
UltraSparc-IIIi/UltraSparc-T1 respectively.
>
> 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...
Applying the latest OS cluster for Solaris 10 patches did not help. Patch
details:
NAME: Recommended OS Cluster Solaris 10 SPARC
DATE: 2010.08.10
However, http://sunsolve.sun.com was not very clear in whether this patch
cluster included a fix for libdevnfo shared library. The README of the patch
bundle did not say anything about libdevnfo.
>
> > 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.
>
I now rebuilt the OpenSSL lib with -no-asm, which produces good/working code.
I've added/attached truss output on our application, with and without
OPENSSL_sparcv9cap env. var set. When this variable is not set, I get a core
dump.
As you can see from the truss output, iterating devices results in a coredump.
This may indeed point to a Sun Solaris issue.
KD.
truss.tar.gz
Description: truss.tar.gz
