Please remember that the lists are for discussion, not proper requests. If you want to see this acted upon, you should probably follow an ITS as seen at www.openldap.org/its.
On Fri, 31 Mar 2006, Xavier wrote: > Hello, > > I'm having the folowing problem with OpenLDAP 2.3.20 (stable 20060227) > which acts as a replica. > the segfault occurs when my master LDAP server which is 2.0.27 sends an > ldap modify on a DN that doesn't exists. ( I know this shouldn't happen > because this means that there is a synchonisation problem ) > I think it would be better to have an error instead of a segmentation > fault. > > e is NULL in the call of cache_return_entry_rw() > > Following is the backtrace of the crash. > > I hope this will help. > > Kind regards. > > > <= str2entry(ou=testrb,ou=ORG,o=CORP) -> 0xa218a08 > <= id2entry_r( 78335 ) 0xa218a08 (disk) > ====> cache_return_entry_r( 78335 ): created (0) > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread -1213113424 (LWP 16455)] > cache_return_entry_rw (cache=0xa1c220c, e=0x0, rw=1) at cache.c:111 > 111 assert( e->e_private != NULL ); > (gdb) backtrace > #0 cache_return_entry_rw (cache=0xa1c220c, e=0x0, rw=1) at cache.c:111 > #1 0x080bfb72 in ldbm_back_modify (op=0xa216f98, rs=0xb7b15230) at > modify.c:298 > #2 0x08070496 in fe_op_modify (op=0xa216f98, rs=0xb7b15230) at > modify.c:395 > #3 0x08070f04 in do_modify (op=0xa216f98, rs=0xb7b15230) at > modify.c:200 > #4 0x0805e28d in connection_operation (ctx=0xb7b152b0, arg_v=0xa216f98) > at connection.c:1307 > #5 0x0810b38f in ldap_int_thread_pool_wrapper (xpool=0xa184da8) at > tpool.c:480 > #6 0x00739341 in start_thread () from /lib/tls/libpthread.so.0 > #7 0x0063d6fe in clone () from /lib/tls/libc.so.6 >
