[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openssl-dev
Subject:    [openssl.org #293] Openssl-0.9.6g on Solaris, broken shared libraries
From:       "René Berber via RT" <rt () openssl ! org>
Date:       2002-09-29 20:41:45
[Download RAW message or body]



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                       openssl-dev@openssl.org
Automated List Manager                           majordomo@openssl.org


[prev in list] [next in list] [prev in thread] [next in thread]