#47503 modify as root causes a crash when chain on update is configured
Closed: wontfix None Opened 10 years ago by lkrispen.

Working on ticket #314 with current master I got a crash when doing a mod as root. The mod is applied locally and leads to this crash: 0x00007f8a9fd72b02 in write_changelog_and_ruv (pb=0x7f8a8b7fdaa0) at ldap/servers/plugins/replication/repl5_plugins.c:1227 1227 csn_as_string(op_params->csn, PR_FALSE, csn_str)); (gdb) bt #0 0x00007f8a9fd72b02 in write_changelog_and_ruv (pb=0x7f8a8b7fdaa0) at ldap/servers/plugins/replication/repl5_plugins.c:1227 #1 0x00007f8a9fd72493 in multimaster_be_betxnpostop_modify (pb=0x7f8a8b7fdaa0) at ldap/servers/plugins/replication/repl5_plugins.c:961 #2 0x0000003f850a9d97 in plugin_call_func (list=0x2745990, operation=561, pb=0x7f8a8b7fdaa0, call_one=0) at ldap/servers/slapd/plugin.c:1467 #3 0x0000003f850a9c57 in plugin_call_list (list=0x2710320, operation=561, pb=0x7f8a8b7fdaa0) at ldap/servers/slapd/plugin.c:1429 #4 0x0000003f850a7f90 in plugin_call_plugins (pb=0x7f8a8b7fdaa0, whichfunction=561) at ldap/servers/slapd/plugin.c:403 #5 0x00007f8aa0043f18 in ldbm_back_modify (pb=0x7f8a8b7fdaa0) at ldap/servers/slapd/back-ldbm/ldbm_modify.c:753 #6 0x0000003f8509632d in op_shared_modify (pb=0x7f8a8b7fdaa0, pw_change=0, old_pw=0x0) at ldap/servers/slapd/modify.c:1075 #7 0x0000003f85094b40 in do_modify (pb=0x7f8a8b7fdaa0) at ldap/servers/slapd/modify.c:415 #8 0x000000000041507c in connection_dispatch_operation (conn=0x7f8a98162210, op=0x280b470, pb=0x7f8a8b7fdaa0) at ldap/servers/slapd/connection.c:653 #9 0x0000000000416cd9 in connection_threadmain () at ldap/servers/slapd/connection.c:2482 #10 0x0000003e6dc28b46 in ?? () from /usr/lib64/libnspr4.so #11 0x000000390b607d14 in start_thread (arg=0x7f8a8b7fe700) at pthread_create.c:309 #12 0x000000390aef168d in clone () from /usr/lib64/libc.so.6 It is a read only replica without changelog, so this should not happen.

Are there any more details on how to reproduce this? I setup "chain on update" on a consumer, and I did a modify as the root DN on the consumer.

On 1.3.2(master), the update is rejected(err=53). On 1.3.1 is it allowed. Neither of these crash the server.

I followed this document for setting up chain on update: http://directory.fedoraproject.org/wiki/Howto:ChainOnUpdate

with the fix for #314 the updates as root are rejected by default, but it can be configured:
nsslapd-distribution-root-update: local

I only experienced the crash once, created this ticket - but later on local updates as root did no longer crash. So there is a problem, but probably hard to reproduce

Replying to [comment:5 lkrispen]:

with the fix for #314 the updates as root are rejected by default, but it can be configured:
nsslapd-distribution-root-update: local

I only experienced the crash once, created this ticket - but later on local updates as root did no longer crash. So there is a problem, but probably hard to reproduce

Did it crash before your patch or after? Should I be testing 1.3.1, or master with the config change you mentioned?

The crash occured when I started to implement #314, so it was before, but with a state of master late august/early sept.
So I suggest you try with current master and the switch to allow local updates

I have been unable to reproduce this crash. I've tried all kinds of scenarios, consumers, hubs, single masters, changelog/no changelog, etc. I wonder if while implementing ticket #314, the crash was accidentally introduced, and then later accidentally fixed.

Closing ticket.

Metadata Update from @mreynolds:
- Issue assigned to mreynolds
- Issue set to the milestone: 1.3.3 - 10/13 (October)

7 years ago

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/840

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: Invalid)

3 years ago

Login to comment on this ticket.

Metadata