[Issue 9421] SIGSEGV in the MMR synchro
https://bugs.openldap.org/show_bug.cgi?id=9421
--- Comment #2 from Ondřej Kuzník <ondra(a)mistotebe.net> ---
On Tue, Dec 08, 2020 at 11:39:37AM +0000, openldap-its(a)openldap.org wrote:
We are in the process of migrating from a single outdated node to an
up to date
MMR cluster. Through this process we write LSC synchronizations from the old
server to the new server so we can keep the old server around.
Our preliminary tests show that when LSC hammers the ldap using multiple
threads while another node is included in the replication, we get segmentation
faults with the following backtrace:
#0 0x00007f7f578748ef in __strncasecmp_l_avx () from /lib64/libc.so.6
#1 0x000056094a7ca298 in avl_find (root=0x56094bb28820,
data=data@entry=0x7f7e74000cd0, fcmp=fcmp@entry=0x56094a7166a0
<oc_index_name_cmp>) at avl.c:545
#2 0x000056094a716bde in oc_bvfind (ocname=0x7f7e74000cd0) at oc.c:186
#3 oc_bvfind (ocname=ocname@entry=0x7f7e74000cd0) at oc.c:178
#4 0x000056094a70ec5a in objectSubClassMatch (matchp=0x7f7e5fff8c8c,
flags=256, syntax=<optimized out>, mr=<optimized out>, value=<optimized
out>,
assertedValue=0x7f7e74000cd0) at schema_prep.c:214
#5 0x000056094a6e9fb9 in ordered_value_match
(match=match@entry=0x7f7e5fff8c8c, ad=0x56094bb184e0,
mr=mr@entry=0x56094bb09810, flags=flags@entry=256, v1=v1@entry=0x7f7e5810f470,
v2=v2@entry=0x7f7e74000cd0,
text=0x7f7e5fff8c90) at value.c:693
#6 0x000056094a6ec44d in test_ava_filter (op=op@entry=0x7f7e5fff90c0,
e=e@entry=0x56094bb54a88, ava=0x7f7e74000cc8, type=type@entry=163) at
filterentry.c:777
#7 0x000056094a6ecfec in test_filter (op=op@entry=0x7f7e5fff90c0,
e=e@entry=0x56094bb54a88, f=f@entry=0x7f7e74000d08) at filterentry.c:88
#8 0x000056094a6ecc81 in test_filter_and (flist=<optimized out>,
e=0x56094bb54a88, op=0x7f7e5fff90c0) at filterentry.c:879
#9 test_filter (op=op@entry=0x7f7e5fff90c0, e=0x56094bb54a88, f=<optimized
out>) at filterentry.c:118
#10 0x00007f7f5382c58f in syncprov_matchops (op=op@entry=0x7f7e5fff9c80,
opc=opc@entry=0x7f7e58001808, saveit=saveit@entry=0) at syncprov.c:1393
Can you print out the full backtrace (bt full) at least up until this
point and as much of the entry as you can, (masking out any private
data), but definitely the objectclass name in frame 2 above?
Relevant syncrepl and syncprov config might also be helpful.
If we take down the second node, we cannot reproduce the segfaults
anymore.
Let me know if we can provide more information (we can't provide the core dump
since it's full of passwords).
Thanks,
--
You are receiving this mail because:
You are on the CC list for the issue.