389-ds-base

#49967 entry cache corruption after failed MODRDN
Closed: wontfix Opened by lkrispen.

Closed: wontfix
Reopen Issue

Issue Description

if a modrdn fails with operations error, because a plugin fails, the modrdn operation is rejected, but the entry cache has a mixed state

Package Version and Platform

tested with master and 1.3.6

Steps to reproduce

It is hard to reproduce, so far I could only do it by manipulating the plugin rc in gdb:

  • attach gdb to slapd
  • set a breakpoint in ldbm_back_modrdn
  • start the modrdn operation

  • set a breakpoint before calling the txn postop plugins

    if ((retval = plugin_call_plugins(pb, SLAPI_PLUGIN_BE_TXN_POST_MODRDN_FN))) {

  • step into plugi_call_plugins

  • set rc=-1
  • jump to return statement

An example of a test is here:

 ldapmodify -h localhost  -p 39001 -x -D "cn=directory manager" -w password
 dn: cn=yyy,cn=sub3,ou=people,dc=example,dc=com
 changetype: modrdn
 newrdn: cn=y3
 deleteoldrdn: 0
 modifying rdn of entry "cn=yyy,cn=sub3,ou=people,dc=example,dc=com"
 ldap_rename: Operations error (1)

Now do a search for the original dn

 ldapsearch -LLL -o ldif-wrap=no -h localhost  -p 39001 -x -D "cn=directory manager" -w password -b "cn=yyy,cn=sub3,ou=people,dc=example,dc=com" -s base

no result, try for the attempted new rdn:

 ldapsearch -LLL -o ldif-wrap=no -h localhost  -p 39001 -x -D "cn=directory manager" -w     password -b "cn=y3,cn=sub3,ou=people,dc=example,dc=com" -s base 
 dn: cn=y3,cn=sub3,ou=People,dc=example,dc=com
 objectClass: person
 objectClass: top
 sn: yyy,cn=sub3
 description: test-yyy,cn=sub3
 cn: yyy

NOTE: the entry is returned, the dn contains the attempted new value, but the attribute value for cn is the original one.

Now restart the server and the search for the original dn returns the correct result and the search for the new rdn returns nothing - as expected

@lkrispen We could make a plugin that given certain operation conditions triggers failures for us? That way we could create deterministic test failure cases like this.

Metadata Update from @firstyear:
- Custom field component adjusted to None
- Custom field origin adjusted to None
- Custom field reviewstatus adjusted to None
- Custom field type adjusted to None
- Custom field version adjusted to None

Metadata Update from @tbordaz:
- Issue assigned to tbordaz

https://pagure.io/389-ds-base/pull-request/49989

Metadata Update from @mreynolds:
- Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1518320

This patch fixes an entry cache crash a customer was running into! I have a reproducer script for the crash as well

That is a good news that the patch also fixes the crash (https://pagure.io/389-ds-base/issue/49905).
Just a guess how 49905 happens, If the MODRDN fails, the target entry should be on the LRU, but if it remains a reference to it into the DN cache, there is a chance that during later cache lookup we compare the DN of the failing MODRDN target entry with the lookup DN. but at that time the target entry may have been freed.

Metadata Update from @tbordaz:
- Issue close_status updated to: fixed
- Issue status updated to: Closed (was: Open)

487ea32c6..ab4af68ef master

e87985cd1..0a2cc3bdb 389-ds-base-1.3.8 -> 389-ds-base-1.3.8

cb21dc58a..144841524 389-ds-base-1.3.7 -> 389-ds-base-1.3.7

@lkrispen We could make a plugin that given certain operation conditions triggers failures for us? That way we could create deterministic test failure cases like this.

This is a very good idea. I wrote a first draft of such a plugin, see attachment.

And in a first test I found that a failed search preop plugin hangs the client. there is probably more to find.
And it needs handling of internal op entry points.

fail.c

@lkrispen I'm reviewing this now, but it looks good. I think we should open a ticket/PR to accept this because it would be great for testing.

c15488963..68e0d589c 389-ds-base-1.3.6 -> 389-ds-base-1.3.6

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/3026

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: fixed)
Metadata
None
None
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.