[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: (ITS#3456) test018 consumer segfault



Kurt@OpenLDAP.org wrote:

>At 03:28 PM 1/27/2005, you wrote:
>  
>
>>That looks like an Efence error, do you have the multithreading patches 
>>for Efence applied?
>>    
>>
>
>With your patch with -DUSE_PTHREADS, eftest fails.
>With your patch without -DUSE_PTHREAD (and without -DUSE_SEMAPHORE)
>I got:
>
>Program received signal SIGBUS, Bus error.
>EF_memalign (alignment=4, userSize=8, dolock=1) at efence.c:505
>505                     if ( slot->mode == FREE
>(gdb) where
>#0  EF_memalign (alignment=4, userSize=8, dolock=1) at efence.c:505
>#1  0x80e6e04 in memalign (alignment=4, userSize=8) at efence.c:653
>#2  0x80e7231 in malloc (size=8) at efence.c:860
>#3  0x2832ef05 in bn_cmp_part_words () from /usr/lib/libcrypto.so.3
>#4  0x2832f4e4 in CRYPTO_malloc () from /usr/lib/libcrypto.so.3
>#5  0x2832e423 in BN_new () from /usr/lib/libcrypto.so.3
>#6  0x2832e621 in bn_expand2 () from /usr/lib/libcrypto.so.3
>#7  0x2832442f in BN_add_word () from /usr/lib/libcrypto.so.3
>#8  0x8061abf in send_ldap_response (op=0x2d4e7e5c, rs=0x2de64db0)
>    at result.c:456
>#9  0x8061f43 in slap_send_ldap_result (op=0x2d4e7e5c, rs=0x2de64db0)
>    at result.c:607
>#10 0x806bb24 in fe_op_bind (op=0x2d4e7e5c, rs=0x2de64db0) at bind.c:402
>#11 0x806b4a0 in do_bind (op=0x2d4e7e5c, rs=0x2de64db0) at bind.c:204
>#12 0x8056b24 in connection_operation (ctx=0x2de64e3c, arg_v=0x2d4e7e5c)
>    at connection.c:1038
>#13 0x80c71b9 in ldap_int_thread_pool_wrapper (xpool=0x29146fc8) at tpool.c:467
>#14 0x2838c4c8 in _thread_start () from /usr/lib/libc_r.so.4
>#15 0x0 in ?? ()
>
>
>  
>
I note that that code is using ldap_pvt_mp_add_ulong(), i.e. 
BN_add_word(), with a var "bytes" that's actually a "long".  Could this 
be part of the problem?  Could you try casting it to (long)?

diff -u -r1.245 result.c
--- result.c    1 Jan 2005 19:49:50 -0000       1.245
+++ result.c    28 Jan 2005 06:55:14 -0000
@@ -453,7 +453,7 @@
 
        ldap_pvt_thread_mutex_lock( &slap_counters.sc_sent_mutex );
        ldap_pvt_mp_add_ulong( slap_counters.sc_pdu, 1 );
-       ldap_pvt_mp_add_ulong( slap_counters.sc_bytes, bytes );
+       ldap_pvt_mp_add_ulong( slap_counters.sc_bytes, (unsigned 
long)bytes );
        ldap_pvt_thread_mutex_unlock( &slap_counters.sc_sent_mutex );
 
 cleanup:;

I doubt this can do any harm, but just in case...  What version of 
openssl are you using?  I wonder if this may be part of the problem 
(i.e. a bug in openssl allocation?)

p.  





    SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497