[EMAIL PROTECTED] - Tue Jul 22 12:45:26 2003]:

> 
> > However if you could a stack trace
>    when it crashes, also 
> 
> core file = core -- program ``dspwd'' on
>    platform SUNW,Ultra-1
> SIGSEGV: Segmentation Fault
> $c
>    libc.so.1`realfree+0x70(1001da280, 1001da0f0, 342c636e3d442d50,
>    1001bf400, 
> 100000000, 1bf400)
>    libc.so.1`_malloc_unlocked+0x274(180, ffffffff7efb4ee0, 11333c, 0,
>    10002debc, 0
> )
> libc.so.1`malloc+0x20(180, 1, 1, 1001bf400,
>    100000000, 1bf400)
> default_malloc_ex+0x1c(180, 1000a2660, 97,
>    100000000, 1001bf400, 10001bf60)
> CRYPTO_malloc+0x74(1bf400,
>    1000a2660, 97, 80, 100000000, 1)
>    EVP_CipherInit_ex+0xb4(ffffffff7fffebb0, 1000a28b0, a2400,
>    ffffffff7fffe980, 
> ffffffff7fffe970, 0)

OK, this looks like its crashing in the internal malloc() functions
called by CRYPTO_malloc(). The arguments to CRYPTO_malloc() seem OK so
this suggests that malloc() is getting confused. Possible reasons would
include...

1. Some bug in the platforms C runtime library.

2. A compiler bug.

3. Some prior call in OpenSSL such as freeing a block that isn't
malloced or writing to memory it shouldn't which is corrupting the
malloc internals.

This latter case would be easier to track down if OpenSSL was compiled
against a debugging malloc library (there are several freeware ones
available) which would hopefully cause any invalid call to be trapped
when it was made rather than its after effects.

Steve.

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

Reply via email to