Re: Seg Faults with ldapdelete (ITS#53)

[SDaniel@corp2.pagemart.com]

All,

Yet more tests on the core dumping with ldapdelete.
I got OpenLDAP to compile with the --no-threads option on OSF1.
Apparently it has some of the same problems as Solaris does because
a workaround suggested by Kurt (for Solaris) worked like a charm.

Anyway,  the problem still persists.  Only it seems to be
slightly different.

I start up the server.   I issue the following command:
    ldapdelete -h localhost -p 393 -w "xxx" -D "xxx"   
"uid=1339248,o=PageMart.com"

the server crashes.  However it appears to crash in a different place.
Here is the output of -d1 followed by a backtrace.

### -d1
do_bind
do_bind: version 2 dn (cn=Directory Manager) method 128
send_ldap_result 9::Referral:
ldap://infoweb.pagemart.com:390
do_delete
dn2entry_w: dn: "uid=1339248,o=PageMart.com"
=> dn2id( "uid=1339248,o=PageMart.com" )
=> ldbm_cache_open( "/data/ldap393/dn2id.gdbm", 2, 600 )
<= ldbm_cache_open (opened 0)
<= dn2id 94437
=> id2entry_w( 94437 )
=> ldbm_cache_open( "/data/ldap393/id2entry.gdbm", 2, 600 )
<= ldbm_cache_open (opened 1)
=> str2entry
<= str2entry 0x140020040
<= id2entry_w( 94437 ) (disk)
rdwr_Xchk: readers_reading: 0 writer_writing: 1
=> has_children( 94437 )
=> ldbm_cache_open( "/data/ldap393/id2children.gdbm", 2, 600 )
<= ldbm_cache_open (opened 2)
<= has_children 0
rdwr_Xchk: readers_reading: 0 writer_writing: 1
dn2entry_w: dn: "o=PageMart.com"
=> dn2id( "o=PageMart.com" )
=> ldbm_cache_open( "/data/ldap393/dn2id.gdbm", 2, 600 )
<= ldbm_cache_open (cache 0)
<= dn2id 5
=> id2entry_w( 5 )
=> ldbm_cache_open( "/data/ldap393/id2entry.gdbm", 2, 600 )
<= ldbm_cache_open (cache 1)
=> str2entry
<= str2entry 0x140020340
<= id2entry_w( 5 ) (disk)
=> id2children_remove( 5, 94437 )
=> ldbm_cache_open( "/data/ldap393/id2children.gdbm", 2, 600 )
<= ldbm_cache_open (cache 2)
<= id2children_remove 0
=> dn2id_delete( "248,o=PageMart.com" )
=> ldbm_cache_open( "ap393/dn2id.gdbm", 2, 600 )
<= ldbm_cache_open (cache 0)
<= dn2id_delete -1
send_ldap_result 1::
====> cache_return_entry_w
====> cache_return_entry_w
/usr/local/seth/sbin/ldap393: 13105 Memory fault(coredump)

### backtrace

> ladebug /usr/local/seth/libexec/slapd core
Welcome to the Ladebug Debugger Version 4.0-43
 ------------------
object file name: /usr/local/seth/libexec/slapd
core file name: core
Reading symbolic information ...done
Core file produced from executable slapd
Thread terminated at PC 0x120013d80 by signal SEGV
(ladebug) where   
                                                                 

>0  0x120013d80 in op_delete(olist=0x140018c98, op=0x0) operation.c:64
#1  0x120009cd4 in connection_operation(arg_v=0x140023300)   
connection.c:92
#2  0x120031d4c in pthread_create(tid=0x140018c10, attr=0x11ffff190,   
func=0x120009a60, arg=0x140023300) thread.c:534
#3  0x12000a3b4 in connection_activity(conn=0x140023fd0) connection.c:225
#4  0x120009528 in slapd_daemon(port=0x189) daemon.c:365
#5  0x120031d4c in pthread_create(tid=0x14000c280, attr=0x0,   
func=0x1200077a0, arg=0x189) thread.c:534
#6  0x1200071f0 in main(argc=6, argv=0x11ffffa28) main.c:139


Hmmm.  is pthread_create normally called when you have "w/o threads"
compiled in?


If I start up the server again and issue the following:
   ldapdelete -h localhost -p 393 -w "xxx"  -D "xxx" "uid=1339248"

it returns the following:
  deleting entry uid=1339248
  entry removed

however a subsequent ldapsearch will find uid=1339248.

 -seth