On Mon, Aug 26, 2002 at 01:44:25PM -0700, Himanshu Soni wrote:
> Is disabling efence the solution here?
No.
> #0 slotForUserAddress (address=0x40a3def8) at efence.c:568
> 568 if ( slot->userAddress == address )
> (gdb) bt
> #0 slotForUserAddress (address=0x40a3def8) at efence.c:568
> #1 0x80e81c5 in free (address=0x40a3def8) at efence.c:629
> #2 0x8058160 in CRYPTO_free (str=0x40a3def8) at mem.c:248
> #3 0x8059b06 in BN_clear_free (a=0xbf7f6958) at bn_lib.c:268
> #4 0x80a3702 in BN_mod_exp_mont (rr=0xbf7f6ab8, a=0xbf7f6acc,
> p=0x404eefec, m=0x404e6fec, ctx=0x40a03e80,
> in_mont=0x40b0dfb8) at bn_exp.c:460
> #5 0x80ac521 in RSA_eay_mod_exp (r0=0xbf7f6b28, I=0xbf7f6b3c,
> rsa=0x404cafb0) at rsa_eay.c:547
> #6 0x80ab917 in RSA_eay_private_encrypt (flen=34, from=0x409fbefc "0
> 0\f\006\b*\206H\206�\r\002\005\005",
> to=0x409f3f00 "", rsa=0x404cafb0, padding=1) at rsa_eay.c:253
> #7 0x805d494 in RSA_private_encrypt (flen=34, from=0x409fbefc "0
> 0\f\006\b*\206H\206�\r\002\005\005",
> to=0x409f3f00 "", rsa=0x404cafb0, padding=1) at rsa_lib.c:277
> #8 0x80aca84 in RSA_sign (type=4, m=0xbf7f6d00
> "�\201\005��\222\f\001-hֿ�¿i\220�\013\b\207\003",
> m_len=16, sigret=0x409f3f00 "", siglen=0xbf7f6d54, rsa=0x404cafb0)
> at rsa_sign.c:129
> #9 0x80e455c in EVP_SignFinal (ctx=0xbf7f6d6c, sigret=0x409f3f00 "",
> siglen=0xbf7f6d54, pkey=0x404f6fe8)
> at p_sign.c:109
> #10 0x80b8e46 in ASN1_sign (i2d=0x80ba790 <i2d_X509_CINF>,
> algor1=0x40957ff8, algor2=0x40b33ff8,
> signature=0x40b35ff0, data=0x408aefd8
> "�_�@�?\231@�\177\225@�??@�\217\223@�O\223@�\177�@",
> pkey=0x404f6fe8, type=0x80ff080) at a_sign.c:185
> #11 0x8087759 in X509_sign (x=0x40902fac, pkey=0x404f6fe8, md=0x80ff080)
> at x_all.c:94
> #12 0x804f97c in scsr (conf=0x403cafa0, logctxt=0x40468fec,
> reqInfo=0x408f8fdc) at scsr.c:192
> #13 0x804c574 in signcsr (trx_id=13880) at openssld.c:373
> #14 0x804ce36 in ProcessRequest (inarg=0x40963ff8) at openssld.c:552
> #15 0x4001e065 in pthread_start_thread (arg=0xbf7ffc00) at manager.c:274
> (gdb)
>From the backtrace it seems, that there is a problem in CRYPTO_free()
called from BN_clear_free() etc. This might be due to a stale pointer
or by a off-by-one error. efence just points out the problem.
I have never looked into the bignum library, but from the backtrace
it seems, that something might be wrong in bignum's memory management...
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
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
