https://bugs.openldap.org/show_bug.cgi?id=9584
--- Comment #1 from Howard Chu hyc@openldap.org --- (In reply to Ondřej Kuzník from comment #0)
Looking into this crash: https://git.openldap.org/openldap/openldap/-/jobs/7286
The thread in question is running a plain syncrepl refresh while another thread seems to have done the same. This thread fetched the entryUUID attribute of the 'cn=config' entry as 'a' and in the meantime, that entry has been rewritten, with 'a' presumably cleaned up and returned to the pool, so addressing a->a_nvals[0] is a NULL-dereference now.
I don't see how this could happen. In order for any consumer to write to cn=config, all other threads must be paused. There is no point where one consumer will have retrieved any entry from cn=config and then paused itself, giving any window for another consumer to rewrite the entry out from under it.
In particular, the stacktrace for the crashed thread is:
#0 0x0000557332297336 in nonpresent_callback (op=<optimized out>, rs=0x7ff39d52dcb0) at ../../../servers/slapd/syncrepl.c:5681 #1 0x0000557332244ef8 in slap_response_play (op=op@entry=0x7ff39d52e4f0, rs=rs@entry=0x7ff39d52dcb0) at ../../../servers/slapd/result.c:567 #2 0x0000557332246c30 in slap_send_search_entry (op=0x7ff39d52e4f0, rs=0x7ff39d52dcb0) at ../../../servers/slapd/result.c:1072 #3 0x000055733221c154 in config_send (op=op@entry=0x7ff39d52e4f0, rs=rs@entry=0x7ff39d52dcb0, ce=ce@entry=0x55733339fcd0, depth=depth@entry=0) at ../../../servers/slapd/bconfig.c:4719 #4 0x000055733221c790 in config_back_search (op=0x7ff39d52e4f0, rs=0x7ff39d52dcb0) at ../../../servers/slapd/bconfig.c:6794 #5 0x00005573322a57f1 in overlay_op_walk (op=op@entry=0x7ff39d52e4f0, rs=rs@entry=0x7ff39d52dcb0, which=which@entry=op_search, oi=oi@entry=0x7ff3941dcaf0, on=<optimized out>) at ../../../servers/slapd/backover.c:706 #6 0x00005573322a594e in over_op_func (op=0x7ff39d52e4f0, rs=0x7ff39d52dcb0, which=op_search) at ../../../servers/slapd/backover.c:766 #7 0x0000557332291b3d in syncrepl_del_nonpresent (op=op@entry=0x7ff39d52e4f0, si=si@entry=0x7ff388108640, uuids=uuids@entry=0x0, sc=sc@entry=0x7ff39d52dfc0, m=3) at ../../../servers/slapd/syncrepl.c:4625 #8 0x000055733229ea1a in do_syncrep2 (si=0x7ff388108640, op=0x7ff39d52e4f0) at ../../../servers/slapd/syncrepl.c:1840 #9 do_syncrepl (ctx=<optimized out>, arg=0x7ff388109cb0) at ../../../servers/slapd/syncrepl.c:2076 #10 0x00007ff3a0fe047e in ?? () #11 0x0000000000000000 in ?? ()
There is nowhere along the call path from frame #4 thru frame #0 where this thread will do a pausecheck. Which means any other consumer trying to modify the config DB necessarily waits for this call path to complete before it can proceed. Which means no other consumer could have changed any attributes out from under this thread.
This might or might not be related to the fix in ITS#8102.