User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6 A simple modrdn request without changing the superiour never returns. The entry is left unchanged. Reproducible: Always Steps to Reproduce: 1. Install 389-ds-base-1.2.6-0.2.a2.el5 x86_64 on CentoS(RHEL) 5.4 x86_64. 2. setup-ds-admin.pl with the suffix "dc=id,dc=polytechnique,dc=edu" 3. Import the attached ldif file : service dirsrv stop; /usr/lib64/dirsrv/slapd-<slapd-id>/ldif2db -n userRoot -i /tmp/ou_only.ldif ; service dirsrv start 4. Use the attached modrdn-deadlock.ldif to make the MODRDN operation : /usr/bin/ldapmodify -x -h localhost -D "cn=Directory Manager" -w secret123 -f modrdn-deadlock.ldif modifying rdn of entry "ou=DG,ou=Organisation,dc=id,dc=polytechnique,dc=edu" rename completed ... ... ... ... Actual Results: ldapmodify never returns, the operation is never performed. "service dirsrv stop" is unable to stop the server. The only way to stop the server turns out to be "kill -9". Expected Results: The server should make the MODRDN operation normally, it should be possible to stop it with /etc/init.d/dirsrv stop. The MODRDN operation is performed on a non-leaf node with a lot of subtrees. The compiled version with the latest git snapshot (this morning) exhibits the same behavior. All this looks like a deadlock of some type. The server is not freezed completely, it continues to answer the search requests though it does not want to shutdown. So some threads are active while others may be waiting for something.
Created attachment 400491 [details] The test case to import into LDAP server
Created attachment 400493 [details] MODRDN that causes a deadlock
The problem is that there is a duplicate ID in the result_idl in moddn_get_children(). In my test, the duplicate IDs are: (gdb) p result_idl->b_ids[26] $33 = 71 (gdb) p result_idl->b_ids[32] $39 = 71
Created attachment 422349 [details] git patch file File: ldap/servers/slapd/back-ldbm/ldbm_modrdn.c Description: To create the ID list for child entries of to-be-renamed entry, an inappropriate function (idl_append) was used. The function expects the passed IDs are sorted. If not sorted, idl_insert should be used instead.
Thanks to Rich for the clue that helped me a lot as well as for reviewing the change! Pushed to master. $ git merge work Updating 849d8b7..29133f2 Fast-forward ldap/servers/slapd/back-ldbm/ldbm_modrdn.c | 6 +++++- 1 files changed, 5 insertions(+), 1 deletions(-) $ git push Counting objects: 13, done. Delta compression using up to 2 threads. Compressing objects: 100% (7/7), done. Writing objects: 100% (7/7), 913 bytes, done. Total 7 (delta 5), reused 0 (delta 0) To ssh://git.fedorahosted.org/git/389/ds.git 849d8b7..29133f2 master -> master
[root@testvm slapd-testvm]# /usr/lib64/dirsrv/slapd-testvm/ldif2db -n iddb -i /usr/lib64/dirsrv/slapd-testvm/ou_only.ldif importing data ... [19/May/2011:19:49:51 +051800] - WARNING: Import is running with nsslapd-db-private-import-mem on; No other process is allowed to access the database [19/May/2011:19:49:51 +051800] - check_and_set_import_cache: pagesize: 4096, pages: 249236, procpages: 50114 [19/May/2011:19:49:51 +051800] - WARNING: After allocating import cache 398776KB, the available memory is 598168KB, which is less than the soft limit 1048576KB. You may want to decrease the import cache size and rerun import. [19/May/2011:19:49:51 +051800] - Import allocates 398776KB import cache. [19/May/2011:19:49:51 +051800] - import iddb: Beginning import job... [19/May/2011:19:49:51 +051800] - import iddb: Index buffering enabled with bucket size 100 [19/May/2011:19:49:52 +051800] - import iddb: Processing file "/usr/lib64/dirsrv/slapd-testvm/ou_only.ldif" [19/May/2011:19:49:52 +051800] - import iddb: Finished scanning file "/usr/lib64/dirsrv/slapd-testvm/ou_only.ldif" (158 entries) [19/May/2011:19:49:52 +051800] - import iddb: Workers finished; cleaning up... [19/May/2011:19:49:52 +051800] - import iddb: Workers cleaned up. [19/May/2011:19:49:53 +051800] - import iddb: Cleaning up producer thread... [19/May/2011:19:49:53 +051800] - import iddb: Indexing complete. Post-processing... [19/May/2011:19:49:53 +051800] - import iddb: Flushing caches... [19/May/2011:19:49:53 +051800] - import iddb: Closing files... [19/May/2011:19:49:53 +051800] - All database threads now stopped [19/May/2011:19:49:53 +051800] - import iddb: Import complete. Processed 158 entries in 2 seconds. (79.00 entries/sec) [root@testvm slapd-testvm]# service dirsrv start Starting dirsrv: testvm... [ OK ] [root@testvm slapd-testvm]# [root@testvm slapd-testvm]# cd - /home/amsharma/data [root@testvm data]# ldapmodify -h localhost -p 389 -D "cn=Directory Manager" -w Secret123 -f modrdn-deadlock.ldif modifying rdn of entry "ou=DG,ou=Organisation,dc=id,dc=polytechnique,dc=edu" ldapsearch # X10, ELEVE, DE, DGAE, DirGen, Organisation, id.polytechnique.edu dn: ou=X10,ou=ELEVE,ou=DE,ou=DGAE,ou=DirGen,ou=Organisation,dc=id,dc=polytechn ique,dc=edu description: ELEVE X10 ou: X10 objectClass: top objectClass: organizationalunit