Bug 800215 - Certain CMP operations hang or cause ns-slapd to crash
Summary: Certain CMP operations hang or cause ns-slapd to crash
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: 389-ds-base
Version: 6.3
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: rc
: ---
Assignee: Rich Megginson
QA Contact: IDM QE LIST
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-03-06 02:09 UTC by Rich Megginson
Modified: 2012-06-20 07:14 UTC (History)
4 users (show)

Fixed In Version: 389-ds-base-1.2.10.2-3.el6
Doc Type: Bug Fix
Doc Text:
Cause: concurrent compare operations on virtual attrs Consequence: hang Fix: an internal loop was incorrectly handled, fixed the loop issue Result: no more hang from concurrent compare ops
Clone Of:
Environment:
Last Closed: 2012-06-20 07:14:52 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2012:0813 normal SHIPPED_LIVE Low: 389-ds-base security, bug fix, and enhancement update 2012-06-19 19:29:15 UTC

Description Rich Megginson 2012-03-06 02:09:38 UTC
cloned from https://fedorahosted.org/389/ticket/305

Comment 1 Jenny Severance 2012-03-06 13:16:02 UTC
Need steps to reproduce/verify this issue.

Comment 2 Rich Megginson 2012-03-06 17:24:04 UTC
create a directory server instance and use the Example.ldif database with the dc=example,dc=com suffix

using the console or ns-newpwpolicy.pl, create a subtree password policy at dc=example,dc=com and ou=people,dc=example,dc=com - then create a per-user password policy for uid=scarter,ou=people,dc=example,dc=com

do an ldapsearch like this:

ldapsearch -xLLL -D "cn=directory manager" -W -b dc=example,dc=com uid=scarter pwdpolicysubentry

to verify that scarter has the per-user policy, and search

ldapsearch -xLLL -D "cn=directory manager" -W -b dc=example,dc=com uid=alutz pwdpolicysubentry

to verify that alutz has the policy set on ou=people

then, do ldapsearches like this:

ii=10 ; while [ $ii -gt 0 ] ; do
ldapsearch -xLLL -D "cn=directory manager" -w thepassword -b dc=example,dc=com '(pwdpolicysubentry=*)' \* pwdpolicysubentry > /dev/null 2>&1 & ii=`expr $ii - 1` ; done

Mark - anything to add?

Comment 4 Rich Megginson 2012-03-13 19:49:29 UTC
To ssh://rmeggins@pkgs.devel.redhat.com/rpms/389-ds-base
   81baa46..9aeb581  rhel-6.3 -> rhel-6.3
Commit 9aeb581741ad5a062ac0b23795b59acf31c33896

Comment 5 mreynolds 2012-05-11 14:31:59 UTC
[1]  create a DS instance using "dc=example,dc=com"
[2]  import Example.ldif
[3]  Setup a subtree password policy on ou=people,dc=example,dc=com
[4]  Test the crash:

ii=10 ; while [ $ii -gt 0 ] ; do
ldapsearch -xLLL -D "cn=directory manager" -w thepassword -b dc=example,dc=com
'(pwdpolicysubentry=*)' \* pwdpolicysubentry > /dev/null 2>&1 & ii=`expr $ii -
1` ; done


[5]  Test the hang

ii=10 ; while [ $ii -gt 0 ] ; do
ldapcompare -x -D "cn=directory manager" -w thepassword "uid=scarter,ou=people,dc=example,dc=com" 
pwdpolicysubentry:on > /dev/null 2>&1 & ii=`expr $ii -1` ; done

Comment 6 mreynolds 2012-05-25 14:41:32 UTC
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Cause: concurrent compare operations on virtual attrs
Consequence: hang
Fix: an internal loop was incorrectly handled, fixed the loop issue
Result: no more hang from concurrent compare ops

Comment 7 Sankar Ramalingam 2012-05-30 19:34:17 UTC
Followed the reproducible steps given in the comment #2 and comment #5. I did not observe any hang/crash. Hence, marking the bug as verified.

Comment 8 errata-xmlrpc 2012-06-20 07:14:52 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHSA-2012-0813.html


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