New subject: [Issue 9789] syncprov uses a thread-local counters for the detached op

25 Jan 2022


      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
-- 
You are receiving this mail because:
You are on the CC list for the issue.

[Issue 9789] New: syncprov uses a thread-local counters for the detached op