Bug 574101 - MODRDN request never returns - possible deadlock
Summary: MODRDN request never returns - possible deadlock
Alias: None
Product: 389
Classification: Retired
Component: Database - General
Version: 1.2.6
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Noriko Hosoi
QA Contact: Viktor Ashirov
Depends On:
Blocks: 389_1.2.6 639035
TreeView+ depends on / blocked
Reported: 2010-03-16 16:05 UTC by Andrey Ivanov
Modified: 2015-12-07 16:47 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2015-12-07 16:47:21 UTC

Attachments (Terms of Use)
The test case to import into LDAP server (67.76 KB, text/plain)
2010-03-16 16:18 UTC, Andrey Ivanov
no flags Details
MODRDN that causes a deadlock (168 bytes, text/plain)
2010-03-16 16:20 UTC, Andrey Ivanov
no flags Details
git patch file (1.49 KB, patch)
2010-06-08 20:40 UTC, Noriko Hosoi
nhosoi: review?
rmeggins: review+
Details | Diff

Description Andrey Ivanov 2010-03-16 16:05:46 UTC
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.

Comment 1 Andrey Ivanov 2010-03-16 16:18:57 UTC
Created attachment 400491 [details]
The test case to import into LDAP server

Comment 2 Andrey Ivanov 2010-03-16 16:20:38 UTC
Created attachment 400493 [details]
MODRDN that causes a deadlock

Comment 3 Rich Megginson 2010-03-25 02:19:32 UTC
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

Comment 4 Noriko Hosoi 2010-06-08 20:40:52 UTC
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.

Comment 5 Noriko Hosoi 2010-06-08 21:00:23 UTC
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
 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

Comment 6 Amita Sharma 2011-05-19 14:29:41 UTC
[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 -
[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"

# 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
description: ELEVE X10
ou: X10
objectClass: top
objectClass: organizationalunit

Note You need to log in before you can comment on or make changes to this bug.