Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 7): Bug 1518320
Description of problem: crash in ns-slapd when attempting to add a dn to hash. What is strange is that the value is attempted to be added during DEL operation (shouldn't the value be deleted from the hash ?) My findings in private comments. #0 __strcmp_sse42 () at ../sysdeps/x86_64/multiarch/strcmp-sse42.S:164 #1 0x00007fcb5cc9b1ec in entry_same_dn (e=<optimized out>, k=0x561251f093a0) at ldap/servers/slapd/back-ldbm/cache.c:142 #2 0x00007fcb5cc9b3ee in add_hash (ht=0x561235944000, key=key@entry=0x561251f093a0, keylen=<optimized out>, entry=entry@entry=0x56124e195440, alt=alt@entry=0x7fcb236c73d0) at ldap/servers/slapd/back-ldbm/cache.c:191 #3 0x00007fcb5cc9c8aa in entrycache_add_int (cache=cache@entry=0x5612358ee3c8, e=0x56124e195440, state=state@entry=2, alt=alt@entry=0x0) at ldap/servers/slapd/back-ldbm/cache.c:1297 #4 0x00007fcb5cc9cb3d in cache_add_tentative (cache=cache@entry=0x5612358ee3c8, e=<optimized out>, alt=alt@entry=0x0) at ldap/servers/slapd/back-ldbm/cache.c:1497 #5 0x00007fcb5ccd201d in ldbm_back_delete (pb=0x7fcb236c7a50) at ldap/servers/slapd/back-ldbm/ldbm_delete.c:717 #6 0x00007fcb6875efd0 in op_shared_delete (pb=pb@entry=0x7fcb236c7a50) at ldap/servers/slapd/delete.c:331 #7 0x00007fcb6875f352 in do_delete (pb=pb@entry=0x7fcb236c7a50) at ldap/servers/slapd/delete.c:97 #8 0x0000561233bd8642 in connection_dispatch_operation (pb=0x7fcb236c7a50, op=0x561237af44e0, conn=0x561237241e38) at ldap/servers/slapd/connection.c:623 #9 connection_threadmain () at ldap/servers/slapd/connection.c:1772 #10 0x00007fcb66b119bb in _pt_root (arg=0x5612371e1440) at ../../../nspr/pr/src/pthreads/ptthread.c:216 #11 0x00007fcb664b1e25 in start_thread (arg=0x7fcb236c8700) at pthread_create.c:308 #12 0x00007fcb65d9334d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Metadata Update from @firstyear: - Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1518320
Metadata Update from @mreynolds: - Custom field component adjusted to None - Custom field origin adjusted to None - Custom field reviewstatus adjusted to None - Custom field type adjusted to None - Custom field version adjusted to None - Issue assigned to firstyear - Issue set to the milestone: 1.3.7.0 (was: 0.0 NEEDS_TRIAGE)
Having a brief read of the code and the errors, I think this may be an entry cache related issue. It looks like it's failing to hash to the dn of the entry because it's been removed. I would need more time to study this to be 100% sure, but this seems like a hugely unlikely case, and other improvements to transactionality of the entry cache may resolve it as this is a known "problem area" for multithread safety in some aspects (IE transaction rollback).
yes, at first sight it looks like an entry cache issue. But the customer claims that disabling the ndn cache prevents the crash and as soon as they enable the ndn cache the crashes appear. I do not see why, but we cannot ignore this fact.
They are able to produce this reliably? Interesting, I'll investigate more when I can.
Have we had more reports of this? I think that the investigation into this was stalled due to my untimely departure.
I know that @mreynolds has done a fair bit on entry cache safety improvements, so I wonder if those have helped to fix this issue.
This is a duplicate of the other entry cache corruption issues. Closing...
Metadata Update from @mreynolds: - Issue close_status updated to: duplicate - Issue status updated to: Closed (was: Open)
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/2536
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.