Full_Name: Christian Forster Version: 1.1.1 (CVS: HEAD) OS: Linux/i386 URL: Submission from: (NULL) (131.188.2.7) Hi! This is an other slapd deadlock problem. I'm still using my test database (->ITS#24). Execute the following command: ldapdelete -D "cn=normalUser, O=YOUR ORGANIZATION NAME, C=US" -w 123 cn=normalUser, O=YOUR ORGANIZATION NAME, C=US ldap_delete: Insufficient access Ok, everything seems fine. But have a look at "top": PID USER PRI NI SIZE RSS SHARE STAT LIB %CPU %MEM TIME COMMAND 566 root 0 0 968 892 516 R 0 84.2 1.4 1:19 slapd Pid 566 is the tread that handled my connection. slapd still accepts new connections, but pid 566 has crashed. Perhaps gdb can provide you with additional informations: Attaching to program `/usr/src/ldap/servers/slapd/.libs/slapd', Pid 566 0x400e9767 in ?? () (gdb) bt #0 0x400e9767 in ?? () #1 0x80623ad in ?? () #2 0x804eadb in strtok_quote (line=0x8079668 "cn=normalUser, O=YOUR OR\001", sep=0x0) at config.c:461 #3 0x8059703 in lutil_MD5Transform (buf=0x80764c4, inraw=0x8079668 "cn=normalUser, O=YOUR OR\001") at md5.c:266 #4 0x8059724 in lutil_MD5Transform (buf=0x80764c4, inraw=0x8079668 "cn=normalUser, O=YOUR OR\001") at md5.c:268 #5 0x805accc in _fini () #6 0x805270d in access_allowed (be=0x40126628, conn=0x8078e20, op=0x400807e0, e=0xbf7ffe98, attr=0x40078357 "P�����\215v", val=0x807a440, dn=0x40078290 "U\211�\201�\024\001", access=134711316) at acl.c:69 #7 0x804b9de in get_filter (conn=0x807a440, ber=0x40078290, filt=0x8078814, fstr=0xbf7fff74) at filter.c:75 #8 0x40078357 in ?? () (gdb) Slapd log (-d 1): ber_get_next ber_get_next: tag 0x30 len 60 contents: do_bind ber_scanf fmt ({iato}) ber: do_bind: version 2 dn (cn=normalUser,O=YOUR ORGANIZATION NAME,C=US) method 128 dn2entry_r: dn: cn=normalUser,O=YOUR ORGANIZATION NAME,C=US => dn2id( "cn=normalUser,O=YOUR ORGANIZATION NAME,C=US" ) => ldbm_cache_open( "/var/ldap/test/dn2id.dbb", 66, 600 ) <= ldbm_cache_open (cache 0) <= dn2id 3 => id2entry_r( 3 ) ====> cache_find_entry_dn2id: found id: 3 rw: 0 <= id2entry_r 0x8085518 (cache) ====> cache_return_entry_r send_ldap_result 0:: ber_get_next ber_get_next: tag 0x30 len 50 contents: do_delete ber_scanf fmt (a) ber: dn2entry_w: dn: cn=normalUser,O=YOUR ORGANIZATION NAME,C=US => dn2id( "cn=normalUser,O=YOUR ORGANIZATION NAME,C=US" ) => ldbm_cache_open( "/var/ldap/test/dn2id.dbb", 66, 600 ) <= ldbm_cache_open (cache 0) <= dn2id 3 => id2entry_w( 3 ) ====> cache_find_entry_dn2id: found id: 3 rw: 1 <= id2entry_w 0x8085518 (cache) rdwr_Xchk: readers_reading: 0 writer_writing: 1 => has_children( 3 ) => ldbm_cache_open( "/var/ldap/test/id2children.dbb", 66, 600 ) <= ldbm_cache_open (opened 3) <= has_children 0 => dnpat: [1] .* nsub: 0 => acl_get: [1] global ACL match => string_expand: pattern: CN=ROOTS, O=YOUR ORGANIZATION NAME, C=US => string_expand: expanded: CN=ROOTS, O=YOUR ORGANIZATION NAME, C=US => ldbm_back_group: bdn: CN=ROOTS, O=YOUR ORGANIZATION NAME, C=US => ldbm_back_group: edn: CN=NORMALUSER,O=YOUR ORGANIZATION NAME,C=US => ldbm_back_group: objectClass: groupOfNames attrName: member => ldbm_back_group: tdn: CN=NORMALUSER,O=YOUR ORGANIZATION NAME,C=US dn2entry_r: dn: CN=ROOTS, O=YOUR ORGANIZATION NAME, C=US => dn2id( "CN=ROOTS, O=YOUR ORGANIZATION NAME, C=US" ) => ldbm_cache_open( "/var/ldap/test/dn2id.dbb", 66, 600 ) <= ldbm_cache_open (cache 0) <= dn2id 4 => id2entry_r( 4 ) ====> cache_find_entry_dn2id: found id: 4 rw: 0 <= id2entry_r 0x807a950 (cache) ====> cache_return_entry_r <= check a_dnpat: .* => string_expand: pattern: .* => string_expand: expanded: .* => regex_matches: string: CN=NORMALUSER,O=YOUR ORGANIZATION NAME,C=US => regex_matches: rc: 0 matches send_ldap_result 50:: ber_get_next ber_get_next: tag 0x30 len 5 contents: ====> cache_return_entry_w ====> cache_return_entry_r ber_get_next ber_get_next on fd 7 failed errno 0 (Success) *** got 0 of 0 so far do_unbind Btw: On Linux/sparc SLAPD crashes completely. Happy new year, Christian
Christian, I've committed a fix. Please test. At 09:55 PM 1/3/99 GMT, kurt@OpenLDAP.org committed: >Update of /repo/OpenLDAP/pkg/ldap/servers/slapd/back-ldbm >Modified Files: > delete.c 1.8 -> 1.9 >Log Message: >entry pointer 'p' must be initialized. Should fix ITS#31. You can use CVSweb to generate a patch: http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/back-shell/delete.c.diff?r1=1.8&r2=1.9 Kurt
changed notes changed state Open to Test moved from Incoming to Software
changed state Test to Release
At 10:07 PM 1/3/99 GMT, Kurt@OpenLDAP.org wrote: >Christian, >You can use CVSweb to generate a patch: The previous URL was incorrect (should have been back-ldbm not back-shell). The fix passes my tests so I have committed it to REL_ENG_1_1. http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/back-ldbm/delete.c.diff?r1=1.3.2.5&r2=1.3.2.6
I think URL for patch is actually: http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/back-ldbm/delete.c.diff?r1=1.8&r2=1.9 Kurt@OpenLDAP.org wrote: > > Christian, > > I've committed a fix. Please test. > > At 09:55 PM 1/3/99 GMT, kurt@OpenLDAP.org committed: > >Update of /repo/OpenLDAP/pkg/ldap/servers/slapd/back-ldbm > >Modified Files: > > delete.c 1.8 -> 1.9 > >Log Message: > >entry pointer 'p' must be initialized. Should fix ITS#31. > > You can use CVSweb to generate a patch: > http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/back-shell/delete.c.diff?r1=1.8&r2=1.9 > > Kurt -- Brad.Rubenstein@GS.COM Fixed Income Currency & Commodity Strategies Goldman, Sachs & Co.
changed notes
moved from Software to Software Bugs
changed notes changed state Release to Closed
Fix applied to -devel and rel_eng_1_1. To be released in 1.1.3.