Bug description:

Make and make test succeed, but the test programs are linked against the static 
libraries, never against the shared libraries, so if there is a problem with the 
shared libraries (and there is in my system, all applications linked against them core 
dump) it's not detected.

The problem is probably not with the openssl shared libraries but they fail to work 
when used.  I haven't found where exactly is the problem, but for reference here's the 
complete information.

make report returns:

OpenSSL self-test report:

OpenSSL version:  0.9.6h-dev
Last change:      Don't impose a 16-byte length minimum on session IDs in...
Options:          --prefix=/usr/local/ssl threads shared no-asm
OS (uname):       SunOS legosoft 5.8 Generic_108528-14 sun4m sparc SUNW,SPARCstation-5
OS (config):      sun4m-whatever-solaris2
Target (default): solaris-sparcv8-gcc
Target:           solaris-sparcv8-gcc
Compiler:         Configured with: ../gcc-3.2/configure --prefix=/opt/gnu 
--with-gnu-as --with-gnu-ld --disable-multilib --enable-threads 
--enable-languages=c,c++,objc,java --enable-libgcj --disable-nls
Thread model: posix
gcc version 3.2

Test passed.

Note: This is the last recompile I did, I started with version 0.9.6g, then downloaded 
the last snapshot and tried again, then disabled use of assembler, then disabled 
optimization.  Also tested the recommendation from bug report #29: re-linked without 
the -Wl,-Bsymbolic parameter, same result.

To test the shared libraries I took a small program (adapted and corrected from the 
configure script of openSsh):

#include <string.h>
#include <openssl/crypto.h>

int main(void) { return(SSLeay() == OPENSSL_VERSION_NUMBER ? 0 : 1); }

And compiled with:

gcc -o test -pipe -g -Wall -Wpointer-arith -Wno-uninitialized -I../include -L.. -R.. 
test.c -lpam -ldl -lz -lsocket -lnsl -lcrypto

Running it, in all tested variations, results in "Segmentation Fault (core dumped)"

The stack traceback is:

GNU gdb 5.0
[snip]
This GDB was configured as "sparc-sun-solaris2.8"...
(gdb) r
Starting program: /home/rberber/openssl-0.9.6-stable-SNAP-20020925/test/test 

Program received signal SIGSEGV, Segmentation fault.
0xef4a6224 in __register_frame_info_bases (begin=0xef4c0000, ob=0xef4c0000, 
    tbase=0x0, dbase=0x0) at ../../gcc-3.0.3/gcc/unwind-pe.h:211
211     ../../gcc-3.0.3/gcc/unwind-pe.h: No such file or directory.
(gdb) where
#0  0xef4a6224 in __register_frame_info_bases (begin=0xef4c0000, 
    ob=0xef4c0000, tbase=0x0, dbase=0x0) at ../../gcc-3.0.3/gcc/unwind-pe.h:211
#1  0xef4a62a0 in __register_frame_info (begin=0xef4c0000, ob=0xef4c0000)
    at ../../gcc-3.0.3/gcc/unwind-pe.h:211
#2  0xef4e3f18 in frame_dummy ()
   from /home/rberber/openssl-0.9.6-stable-SNAP-20020925/test/../libcrypto.so.0.9.6
#3  0xef4e3e00 in _init ()
   from /home/rberber/openssl-0.9.6-stable-SNAP-20020925/test/../libcrypto.so.0.9.6
#4  0xef7cc1ec in ?? ()
#5  0xef7cbae4 in ?? ()
#6  0xef7d6fdc in ?? ()
#7  0xef7c2a50 in ?? ()

I think only #2 abd #3 are significant, gdb is reporting bogus information which 
include a path with gcc-3.0.3 which never has existed on this machine.  Perhaps all 
the information is bogus since I haven't been able to put a breakpoint at the _init() 
or frame_dummy() routines, one is not found, the later is in another library not 
libcrypto.

-- 
René Berber

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [EMAIL PROTECTED]
Automated List Manager                           [EMAIL PROTECTED]

Reply via email to