https://bugs.openldap.org/show_bug.cgi?id=10591
--- Comment #4 from Howard Chu hyc@openldap.org --- Thanks for the report, but the analysis makes no sense and cannot be correct.
You state
"Access to the tree is correctly serialised at all three sites (`ldap_avl_find` at :2787, `ldap_avl_insert` at :2861, `ldap_avl_delete` at :1589 all under `si_mods_mutex`),"
Therefore the tree must be in the state we expected it to be in. If it is not, then something else very fishy is going on.
Your provided stack trace
#0 sp_avl_cmp (c1=0x7f5778104590, c2=0x7f5f4954e13a) at syncprov.c:433 #1 ldap_avl_delete (root=..., data=c1, fcmp=sp_avl_cmp) at avl.c:199 #2 syncprov_op_cleanup (op, rs) at syncprov.c:1589 #3 slap_cleanup_play at result.c:607 #4 send_ldap_response at result.c:797 #5 slap_send_ldap_result at result.c:926 #6 mdb_add at add.c:389 #7 overlay_op_walk (which=op_add) at backover.c:706 #9 accesslog_response at accesslog.c:1966 #10 slap_response_play at result.c:573 #13 mdb_modify at modify.c:803 #16 syncrepl_message_to_op at syncrepl.c:3271 #17 do_syncrep2 at syncrepl.c:1555 #18 do_syncrepl at syncrepl.c:2197
is impossible, because accesslog.c:1966 explicitly sets a nop callback stack. Therefore slap_cleanup_play cannot invoke syncprov_op_cleanup in this call sequence.
This sounds like an issue specific to your build.