[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Seg Faults with ldapdelete (ITS#53)
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