Hey there, https://github.com/389ds/389-ds-base/pull/4525/files I had a look and I can see a few possible contributing factors, but without a core and the exact state I can't be sure if this is correct. It's all just hypothetical from reading the code. The crash is in deref_do_deref_attr() which is called as part of deref_pre_entry(). This is the SLAPI_PLUGIN_PRE_ENTRY_FN which is called by "./ldap/servers/slapd/result.c:1488: rc = plugin_call_plugins(pb, SLAPI_PLUGIN_PRE_ENTRY_FN);" I think what's important here is that the search is conducted in ./ldap/servers/slapd/opshared.c:818 rc = (*be->be_search)(pb); Is *not* in a transaction. That means that while the single search in be_search() is consistent due to an implied transaction, the subsequent search in deref_pre_entry() is likely conducted in a seperate transaction. This allows for other operations to potentially interleave and cause changes - modrdn or delete would certainly be candidates to cause a DN to be remove between these two points. It would be extremely hard to reproduce as a race condition of course. A question you asked is why don't we get a "no such entry" error or similar? I think that this is because build_candidate_list in ldbm_search.c doesn't actually create an error if the base_candidates list is empty, because an IDL is allocated with a value of 0 (no matching entries). this allows the search to proceed, and there are no errors, and the result set is set to NULL with size 0. I can't see where LDAP_NO_SUCH_OBJECT is set in this process, but without looking further into it, my suspicion is that entries of size 0 WONT return an error condition to internal_search_pb, so it's valid for this to be empty. Anyway, again, this is just reading the code for 20 minutes, and is not a complete in depth investigation, but maybe it's some ideas about what happened? Hope it helps :) — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs, Australia _______________________________________________ 389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@xxxxxxxxxxxxxxxxxxxxxxx
