https://bugs.openldap.org/show_bug.cgi?id=9584
--- Comment #1 from Howard Chu <hyc(a)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.
--
You are receiving this mail because:
You are on the CC list for the issue.