https://bugs.openldap.org/show_bug.cgi?id=9421
--- Comment #6 from Ondřej Kuzník ondra@mistotebe.net --- On Wed, Dec 09, 2020 at 09:09:09AM +0000, openldap-its@openldap.org wrote:
Thanks, after reviewing the stack trace, in frame 10, can you please print *ss
(gdb) f 10 #10 0x00007fda683ce58f in syncprov_matchops (op=op@entry=0x7fd958cf9f90, opc=opc@entry=0x7fd950121ad0, saveit=saveit@entry=0) at syncprov.c:1393 1393 syncprov.c: No such file or directory. (gdb) print *ss $1 = {s_next = 0x0, s_si = 0x563eaa49b460, s_base = {bv_len = 12, bv_val = 0x7fd98c104c50 "cn=accesslog"}, s_eid = 1, s_op = 0x7fd99014f3b0, s_rid = 0, s_sid = 3, s_filterstr = {bv_len = 46, bv_val = 0x7fd98c000d98 "(&(objectClass=auditWriteObject)(reqResult=0))"}, s_flags = 17, s_inuse = 1, s_res = 0x0, s_restail = 0x0, s_mutex = {__data = {__lock = 1, __count = 0, __owner = 37086, __nusers = 1, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = "\001\000\000\000\000\000\000\000ސ\000\000\001", '\000' <repeats 26 times>, __align = 1}}
Looking at op2, o_req_dn and o_req_ndn values look suspect and seems some memory has been overwritten. Can you reproduce it with a non-optimised build, getting the output of "thread apply bt all", removing any private data?
Or even better, if it happens often enough in your environment, does running under valgrind sound like a feasible undertaking?
Thanks, Ondrej