On Sat, Jan 11, 2003 at 12:23:12AM -0800, Raymond C.Rodgers wrote:
> I've managed to get OpenSSL 0.9.7 compiled and installed on a BeOS R5.0.x
> system with BONE (a networking stack), but I'm not able to use OpenSSL for
> reasons I've yet to determine. When I start up a freshly compiled app that
> uses OpenSSL, and has worked fine under previous versions, I'm seeing that
> RAND_egd(), RAND_status(), and other functions (including SSL_connect()) are
> taking minutes to finish executing. I believe these functions are actually
> failing, but I haven't been able to get any details on exactly what's
> happening.
>
> Even "make test" for OpenSSL takes an extremely long time (over 12 hours in
> fact), especially in exptest and randtest. I'm going to attach the
> maketest.log file to this message so anyone that might have a clue what's
> happening might be able to help. According to the maketest.log, the tests
> passed but when in use my application's connection is timing out long before
> it establishes a SSL connection. I hardly think that's successful.
>
> So, what configure options might cause such pitiful performance? I compiled
> OpenSSL with the following options:
> -DOPENSSL_THREADS -DOPENSSL_NO_KRB5 -DTERMIO -m486 l -D_REENTRANT -DSHA1_ASM
> -DMD5_ASM -DELF -DNO_SYSLOG -DNO_SYS_UN_H -DTERMIOS -DL_ENDIAN -fomit-frame-
> pointer -O3 -m486 -DSHA1_ASM -DMD5_ASM -DRMD160_ASM
Use a system call tracer (trace, strace, tusc or whatever it might be called
on your system) to see, whether the program is hanging in some system call.
It might for example happen , that such a behaviour occurs with a blocking
/dev/random device. The OpenSSL library tries to read random bits and only
returns once the amount of bits was received.
In any case, the OpenSSL library does not have any timeouts on such operations,
such that it might even hang completely.
Hangs on I/O operations typically are indicated by a hanging program, that
does however not show any system load. A long running loop is indicated by
a corresponding system load and CPU time used.
If you don't have a system call tracer, you can also run the application
under a debugger and and interrupt during the time in which the application
does not advance. You should then see the location and call stack...
Best regards,
Lutz
--
Lutz Jaenicke [EMAIL PROTECTED]
http://www.aet.TU-Cottbus.DE/personen/jaenicke/
BTU Cottbus, Allgemeine Elektrotechnik
Universitaetsplatz 3-4, D-03044 Cottbus
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
