last few lines of access file are:
[28/Mar/2014:17:25:41 -0400] conn=917 op=4 fd=70 closed - U1 [28/Mar/2014:17:25:41 -0400] conn=915 op=2 UNBIND [28/Mar/2014:17:25:41 -0400] conn=915 op=2 fd=68 closed - U1 [28/Mar/2014:17:26:29 -0400] conn=807 op=79 MOD dn="cn=ResourcePage,ou=1.1,ou=Console,ou=uid\3Dgettes/admin\2Cou\3DAdministrators\2Cou\3DTopologyManagement\2Co\3DNetscapeRoot,ou=UserPreferences,ou=cmu.edu,o=NetscapeRoot" 389-Directory/1.2.11.28 B2014.085.1634 ldap-master-t01.andrew.cmu.edu:636 (/etc/dirsrv/slapd-cmu)
nothing in errors file.
stacktrace and access.buf output attached.
i was quitting the console on fedora workstation.
attachment access.buf
attachment stacktrace.1396042165.txt
this happens regularly. after some reasonable amount of activity with the ldap server and i perform some basic actions with the console - open a directory server and clicking around on the tabs and then i click the go away X in the upper right corner - the MOD operation is performed and the server crashes. i have done this over a dozen times now.
We back ported some fixes to allow updates with multi-valued attributes, especially dn values, to be much faster. Looks like there is a problem with the back port.
I am attaching 6 files. all from the same session (from server start to the crash) of the access log, access buf, audit, errors, stacktrace and the additional gdb commands you requested.
To answer your questions:
(1) Replication is on. 2 MMR to each other and they replicate to 3 readonly (the same readonly) so there are a total of 5 servers. 2 masters and 3 read-only servers. For this particular failure, I am using console connecting to a readonly server which is configured to use one of the master servers. It is the master server that crashes.
(2) the files are attached as crash-27700.tar.
(3) we normally run with a local plugin enabled for kerberos authentication. We turned it off and we still get this crash (this crash is without our plugin). We don't use ref-int, CoS or any other special plugins that I can think of. We are fairly vanilla.
(4) no VLV. You can see all the operations used in this session from startup to crash.
I am happy to answer any other questions you have.
This server was rpmbuild from source if this wasn't made clear.
I very much appreciate your help!
6 files of a complete session providing all info requested crash-27700.tar
Thank you so much for the data. They are very helpful.
Do you happen to replicate "o=netscaperoot"?
It turned out another patch needs to be backported.
Ticket #47448 - Segfault in 389-ds-base-1.3.1.4-1.fc19 when setting up FreeIPA replication
I'm setting this ticket as a duplicate of #47448, and reopening the ticket.
Thanks for your help!
Metadata Update from @gettes: - Issue set to the milestone: 1.2.11.29
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/1090
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: Duplicate)
Login to comment on this ticket.