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: GNU Zip compressed data
