Hi,
>>> 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.
But you can still copy apps/openssl binary to this old system and invoke
it, say with 'version' command-line argument... If it doesn't crash,
then the question would be what is special about *your* application and
what can be done about it.
>>> #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.
I meant "outside" as "in code beyond my control", such as function in
vendor-supplied libraries, e.g. libdevinfo.so or libdl.so. I'd guess,
and truss log suggests that, crash occurs in dlclose (note that it
closed /devices/pseudo/devi...@0:devinfo's file descriptor, meaning that
di_walk_node succeeded). Try to comment out dlclose and see if it helps...
Another possible workaround is to explicitly link your application with
-ldevinfo. In this case dlopen/dlclose would only increment/decrement
reference counter, but not actually do anything upon dlclose. A.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [email protected]
