Bug 923502 - Crash in MODRDN
Summary: Crash in MODRDN
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: 389-ds-base
Version: 6.4
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: ---
Assignee: Rich Megginson
QA Contact: Sankar Ramalingam
Depends On:
Blocks: 929111
TreeView+ depends on / blocked
Reported: 2013-03-20 01:11 UTC by Nathan Kinder
Modified: 2013-11-21 21:05 UTC (History)
6 users (show)

Fixed In Version: 389-ds-base-
Doc Type: Bug Fix
Doc Text:
An out of scope problem for a local variable, in some cases, caused the modrdn operation to terminate unexpectedly with a segmentation fault. This update declares the local variable at the proper place of the function so it does not go out of scope, and the modrdn operation no longer crashes.
Clone Of:
Last Closed: 2013-11-21 21:05:41 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2013:1653 normal SHIPPED_LIVE 389-ds-base bug fix update 2013-11-20 21:53:19 UTC

Description Nathan Kinder 2013-03-20 01:11:45 UTC
This bug is created as a clone of upstream ticket:

Version: main (march 12th 2013)
Testcase: run BOB acceptance tests...but it may be not systematic
Priority: major unless it appears to be a dynamic issue (less chance to occur)

(gdb) where
#0  __strlen_sse2_pminub () at ../sysdeps/x86_64/multiarch/strlen-sse2-pminub.S:39
#1  0x000000370ea1250b in cvt_s (flags=0, prec=<optimized out>, width=<optimized out>, str=<optimized out>, ss=0x7f053ffec8c0)
    at ../../../mozilla/nsprpub/pr/src/io/prprf.c:370
#2  dosprintf (ss=ss@entry=0x7f053ffec8c0, fmt=0x7f055f66e135 "", fmt@entry=0x7f055f66e130 "%s,%s", ap=ap@entry=0x7f053ffec918)
    at ../../../mozilla/nsprpub/pr/src/io/prprf.c:998
#3  0x000000370ea12868 in PR_vsmprintf (fmt=fmt@entry=0x7f055f66e130 "%s,%s", ap=ap@entry=0x7f053ffec918)
    at ../../../mozilla/nsprpub/pr/src/io/prprf.c:1145
#4  0x00007f05630f32d3 in slapi_create_dn_string (fmt=fmt@entry=0x7f055f66e130 "%s,%s") at ldap/servers/slapd/dn.c:1092
#5  0x00007f055f658ada in acl_modified (pb=<optimized out>, optype=<optimized out>, e_sdn=0x7f04e4000f20, change=0x7f053ffeca90)
    at ldap/servers/plugins/acl/acl.c:1801
#6  0x00007f0563136391 in plugin_call_acl_mods_update (pb=pb@entry=0x1b08a60, optype=optype@entry=64)
    at ldap/servers/slapd/plugin_acl.c:192
#7  0x00007f0563125e31 in op_shared_rename (pb=pb@entry=0x1b08a60, passin_args=0) at ldap/servers/slapd/modrdn.c:672
#8  0x00007f0563126534 in do_modrdn (pb=0x1b08a60) at ldap/servers/slapd/modrdn.c:268
#9  0x0000000000416c98 in connection_dispatch_operation (pb=<optimized out>, op=0x1b09530, conn=0x7f0551fb1e10)
    at ldap/servers/slapd/connection.c:588
#10 connection_threadmain () at ldap/servers/slapd/connection.c:2338
#11 0x000000370ea28cf3 in _pt_root (arg=0x1ac7b30) at ../../../mozilla/nsprpub/pr/src/pthreads/ptthread.c:156
#12 0x00000035d7007d14 in start_thread (arg=0x7f053ffef700) at pthread_create.c:309
#13 0x00000035d6cf168d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115

First analyze:
  The problem is that the set of changes provided to the acl_modified callback looks invalid. The pblock contains a valid newrdn but it is not clear for newsuperior or newsuperior_sdn.
   This bug is possibly related to bug fix https://fedorahosted.org/389/ticket/340

Comment 7 Amita Sharma 2013-04-03 11:50:39 UTC
Hi Thierry,

I have tried it ::
[root@mgmt12 ~]# rpm -qa | grep 389

[root@mgmt12 ~]# ldapadd -x -h localhost -p 389 -D "cn=Directory Manager" -w Secret123  << EOF
> dn: uid=testuser1,ou=people,dc=example,dc=com
> cn: ams
> sn: ams
> givenname: ams
> objectclass: top
> objectclass: person
> objectclass: organizationalPerson
> objectclass: inetOrgPerson
> uid: ams
> mail: ams@example.com
> userpassword: amsamsams
adding new entry "uid=testuser1,ou=people,dc=example,dc=com"

[root@mgmt12 ~]# ldapmodify -x -h localhost -p 389 -D "cn=Directory Manager" -w Secret123  << EOF
> dn: uid=testuser1,ou=people,dc=example,dc=com
> changetype: modrdn
> newrdn: uid=testuser1changed
> deleteoldrdn: 1
modifying rdn of entry "uid=testuser1,ou=people,dc=example,dc=com"

[root@mgmt12 ~]# ldapmodify -x -h localhost -p 389 -D "cn=Directory Manager" -w Secret123  << EOF
dn: uid=testuser1changed,ou=people,dc=example,dc=com
changetype: modrdn
newrdn: uid=testuser1       
deleteoldrdn: 1
modifying rdn of entry "uid=testuser1changed,ou=people,dc=example,dc=com"
But I could not reproduce the crash with old version of 389?
Can you please check if something I missed.

I also executed BOB tet suit with the above mentioned version of 389 but again could not reproduce. :(

Comment 11 Amita Sharma 2013-04-08 04:41:14 UTC
Marking the bug Verified Sanity Only.

Comment 12 Sankar Ramalingam 2013-04-15 07:54:35 UTC
Changing back to MODIFIED state since its a RHEL6.5 bug.

Comment 14 Sankar Ramalingam 2013-08-18 05:46:45 UTC
Automated tests in mmrepl/fourwaymmr/fourwaymmr.sh. TET commits r7906 to r7907.

Comment 15 Sankar Ramalingam 2013-08-26 09:26:54 UTC
Bug verified from automated tests for fourwaymmr.

fourwaymmr run Tests PASS      : 100% (24/24)

[bug923502] Instance M1 and M2 are still running after stressing with modrdn operations
Crash in ModRDN when running multiple threads of modrdn operations
TestCase [bug923502] result-> [PASS]

Comment 16 errata-xmlrpc 2013-11-21 21:05:41 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.


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