[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Seg Faults with ldapdelete (ITS#53)
At 08:38 PM 1/27/99 GMT, SDaniel@corp2.pagemart.com wrote:
>Anyway, the problem still persists. Only it seems to be
>slightly different.
Okay, you might walk through with a debugger to see what's
happening.
>### -d1
Please run with -d 5 (TRACE+ARGS) or -d 133 (TRACE+ARGS+ACL).
>do_bind
>do_bind: version 2 dn (cn=Directory Manager) method 128
>send_ldap_result 9::Referral:
>ldap://infoweb.pagemart.com:390
Hmmm... does it happen when bind with something that doesn't
cause a referral? Guess I'll have to try this case on my box.
So we're doing the delete anonymously...
>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" )
What happenned to our dn?
>=> ldbm_cache_open( "ap393/dn2id.gdbm", 2, 600 )
What happenned to our file path?
>>0 0x120013d80 in op_delete(olist=0x140018c98, op=0x0) operation.c:64
When did op become NULL?
>Hmmm. is pthread_create normally called when you have "w/o threads"
>compiled in?
It the mimic'ed pthread_create from -lthread. That's normal.
>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
This *SHOULD* return no such object. ldap_delete requires a DN.