#48312 crash in Managed Entry plugin
Closed: Fixed None Opened 4 years ago by lkrispen.

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


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]:

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 ...."

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]:

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!

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

2 years ago

Login to comment on this ticket.

Metadata