https://bugs.openldap.org/show_bug.cgi?id=9789

Issue ID: 9789 Summary: syncprov uses a thread-local counters for the detached op Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs@openldap.org Reporter: ondra@mistotebe.net Target Milestone: ---

Persistent searches routinely migrate across threads, however they keep using op->o_counters from the original search op which is meant to be thread-local. During shutdown, this counter can be destroyed as the original thread finishes, but the persistent search might still be live somewhere else. At that point, trying to acquire the destroyed sc_mutex fails and the thread usually stalls forever.

slapd-asyncmeta is very likely to suffer from the same issues.

A representative backtrace of this happening: Thread 3 (Thread 0x7f0b7d933640 (LWP 2928392) "slapd"): #0 futex_wait (private=0, expected=2, futex_word=0x7f0b74000ff8) at ../sysdeps/nptl/futex-internal.h:146 #3 0x00007f0b7fd17a05 in ldap_pvt_thread_mutex_lock (mutex=Locked by LWP 0) at thr_posix.c:313 #4 0x0000000000469564 in slap_send_search_entry (op=Search request conn=1003 op=1 = {...}, rs=Search entry = {...}) at result.c:1503 #5 0x00007f0b7f30561c in syncprov_sendresp (op=Search request conn=1003 op=1 = {...}, ri=0x7f0b701eb8e0, so=0x7f0b74102b20, mode=1) at syncprov.c:976 #6 0x00007f0b7f305064 in syncprov_qplay (op=Search request conn=1003 op=1 = {...}, so=0x7f0b74102b20) at syncprov.c:1028 #7 0x00007f0b7f304ecc in syncprov_qtask (ctx=0x7f0b7d932a58, arg=0x7f0b74102b20) at syncprov.c:1086