the following crash was reported in IPA,
(gdb) bt #0 0x00007f806a9466a0 in rename_internal_pb (pb=0x7f800404be40) at ldap/servers/slapd/modrdn.c:350 #1 0x00007f806a94650a in slapi_modrdn_internal_pb (pb=0x7f800404be40) at ldap/servers/slapd/modrdn.c:299 #2 0x00007f805db4a4e4 in mep_rename_managed_entry (origin=0x7f8004046df0, new_dn=0x7f800405c990, old_dn=0x7f8004048ad0) at ldap/servers/plugins/mep/mep.c:1513 #3 0x00007f805db4cc68 in mep_modrdn_post_op (pb=0x7f8033fe6b50) at ldap/servers/plugins/mep/mep.c:2757 #4 0x00007f806a95aa3a in plugin_call_func (list=0x7f806bf3eb90, operation=562, pb=0x7f8033fe6b50, call_one=0) at ldap/servers/slapd/plugin.c:1920 #5 0x00007f806a95a89b in plugin_call_list (list=0x7f806bf6a880, operation=562, pb=0x7f8033fe6b50) at ldap/servers/slapd/plugin.c:1864 #6 0x00007f806a9576e6 in plugin_call_plugins (pb=0x7f8033fe6b50, whichfunction=562) at ldap/servers/slapd/plugin.c:438 #7 0x00007f805e296236 in ldbm_back_modrdn (pb=0x7f8033fe6b50) at ldap/servers/slapd/back-ldbm/ldbm_modrdn.c:1235 #8 0x00007f806a9470eb in op_shared_rename (pb=0x7f8033fe6b50, passin_args=0) at ldap/servers/slapd/modrdn.c:621 #9 0x00007f806a9462eb in do_modrdn (pb=0x7f8033fe6b50) at ldap/servers/slapd/modrdn.c:225 #10 0x00007f806ae36ef4 in connection_dispatch_operation (conn=0x7f8046d64cc0, op=0x7f806c58d6d0, pb=0x7f8033fe6b50) at ldap/servers/slapd/connection.c:614 #11 0x00007f806ae39085 in connection_threadmain () at ldap/servers/slapd/connection.c:1735 #12 0x00007f8068d23cab in _pt_root () from /lib64/libnspr4.so #13 0x00007f80686c4555 in start_thread () from /lib64/libpthread.so.0 #14 0x00007f80683fef3d in clone () from /lib64/libc.so.6
the test case is in ipa ticket: https://fedorahosted.org/freeipa/ticket/5367
attachment 0001-Ticket-48312-Crash-when-doing-modrdn-on-managed-entr.patch
Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1273142
f1e30b0..6f8c555 master -> master commit 6f8c555 Author: Mark Reynolds mreynolds@redhat.com Date: Mon Oct 19 12:53:53 2015 -0400
Looking at the fix I have a new question: if the modrdn changes the rdn to be multivalued MEP just picks the first rdn component. Is this defined in MEP or is this soemtin we should at leas log a warning: "creating managed entry from .. ignoring ...."
Replying to [comment:7 lkrispen]:
MEP always took the first rdn value that it would find by looking it up in the entry(order not being guaranteed). I don't think it makes sense to make the managed entry's DN also multi-valued, but perhaps the managed entry needs some type of unique DN though in the case of multivalued rdns.
I'll open a new ticket to investigate the case of multi-valued rdns in MEP.
Ludwig mentioned FreeIPA hit this issue. Mark, could you please push this fix to 389-ds-base-1.3.4 branch, as well? Thanks!
Hello guys, from FreeIPA,[[BR]] I'd like to ask you for the info about the fixed version. I'm still hitting the bug with 389-ds-base-1.3.4.5-1.fc23 and haven't found 1.3.5 version yet. Thanks!
Replying to [comment:10 alich]:
Its not in 1.3.4, yet...
5d0f573..5b7d42e 389-ds-base-1.3.4 -> 389-ds-base-1.3.4 commit 5b7d42e Author: Mark Reynolds mreynolds@redhat.com Date: Mon Oct 19 12:53:53 2015 -0400
Now it is, but you will need to wait for the next respin of 1.3.4.
Also, we have not done a 1.3.5 build yet, but we will soon (not sure of an exact date though)
Thank you, alich and Mark!
Resetting the targetmilestone to 1.3.4.6. This fix is going to be in the next respin.
Metadata Update from @mreynolds: - Issue assigned to mreynolds - Issue set to the milestone: 1.3.4.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/1643
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: Fixed)
Login to comment on this ticket.