ehlo,
It is not very likely, that record will have the same hash1 and hash2, but it
is possible. In this situation, it does not make sense to remove record twice.
Function sss_mc_rm_rec_from_chain was not robust and sssd_nss could crash
in this situation. It was only possible if record was alone in chain.
The reproducer is very simple name and uid must be the same. (and we should
wait until this record will be removed)
We solved problem with in mmap_cache with commit
4662725ffef62b3b2502481438effa7c8fef9f80
"mmap_cache: Skip records which doesn't have same hash"
Although this problem was solved, user reported another crash
https://bugzilla.redhat.com/show_bug.cgi?id=997406#c12
He wrote:
On my first runs it also did not core dump for days ... also in this
testing cycle I only had those two core dumps yesterday but no more -
eems difficult to reproduce even in my environment.
I was unable to reproduce user crash, so I decided to decrease size of
hash_table (16 times) and I hit this issue. Backtrace from BZ997406#c12 looks
differently; I am still trying to reproduce his issue.
Patch is attached.
LS
BTW: I was very lucky, because I ran into situation, record had the same
hashes for name and uid
(gdb) call sss_mc_hash(mcc, "testbigldap121129", 18)
$18 = 1532
(gdb) p sss_mc_hash(mcc, "121129", 7)
$19 = 1532
(gdb) p mcc->ht_size
$20 = 25000