#47758 ldap server crash
Closed: wontfix None Opened 10 years ago by gettes.

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.


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.

So far, we are not successful to reproduce the problem. Could you give us some more input? 1) Have you configured the replication? If yes, how the topology looks like? 2) Could you enable the audit log and share the contents? We are interested in several operations just before the server crash. 3) Any other specific plug-ins you enable? Such as USN, referential integrity, CoS, etc. 4) Any other specific extended operations you often use? Such as Simple Paged Results search, VLV, etc. And when it happens again {{{ 264 #0 0x00007f831331e71e in valueset_find_sorted (a=0x7f82d9ddebd0, vs=0x7f82d9ddec00, v=0x7f82d804a960, index=0x7f82c87ee61c) at ldap/servers/slapd/valueset.c:948 265 948 if ( (cmp = valueset_value_cmp(a, v, vs->va[vs->sorted[mid]])) > 0) }}} and you see this stacktrace, {{{ 1868 Thread 1 (Thread 0x7f82c87f3700 (LWP 30276)): 1869 #0 0x00007f831331e71e in valueset_find_sorted (a=0x7f82d9ddebd0, vs=0x7f82d9ddec00, v=0x7f82d804a960, index=0x7f82c87ee61c) at ldap/servers/slapd/valueset.c:948 1870 mid = 0 1871 cmp = <value optimized out> 1872 bot = -1 1873 top = 1 }}} could you do following and attach the result to this ticket? (gdb) print vs (gdb) print *vs (gdb) print vs->sorted[0] (gdb) print vs->va (gdb) print vs->va[vs->sorted[0]] (gdb) print a (gdb) print *a (gdb) print v (gdb) print *v Thank you for your help!

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

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

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

3 years ago

Login to comment on this ticket.

Metadata