Re: (ITS#7636) slapd crash when multi-master replication (syncrepl) enabled

[kb9vqf@pearsoncomputing.net]

> Somewhat of a workaround - slapi should not be doing anything here
unless the
> filter was actually changed.
>
> syncprov is using (objectclass=*) which frankly no plugin should be
rewriting,
> so this will cover it for the most part. Aside from that it looks like this
> area of the slapi interaction needs some redesign.
>
> --

Unfortunately the workaround didn't help:

Program received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffe2ca2700 (LWP 29843)]
0x00007ffff5a32475 in *__GI_raise (sig=<optimized out>) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
64      ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or
directory. (gdb) bt
#0  0x00007ffff5a32475 in *__GI_raise (sig=<optimized out>) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x00007ffff5a356f0 in *__GI_abort () at abort.c:92
#2  0x00007ffff5a6d52b in __libc_message (do_abort=<optimized out>,
fmt=<optimized out>) at ../sysdeps/unix/sysv/linux/libc_fatal.c:189 #3 
0x00007ffff5a76d76 in malloc_printerr (action=3, str=0x7ffff5b4f170
"munmap_chunk(): invalid pointer", ptr=<optimized out>) at malloc.c:6283
#4  0x00007ffff63d214a in slapi_op_search_callback (op=0x7fffe2c9fff0,
rs=<optimized out>, prc=<optimized out>) at
../../../../../servers/slapd/slapi/slapi_overlay.c:313
#5  slapi_op_search_callback (op=0x7fffe2c9fff0, rs=<optimized out>,
prc=<optimized out>) at
../../../../../servers/slapd/slapi/slapi_overlay.c:296
#6  0x00007ffff63d304f in slapi_op_func (rs=0x7fffe2c9ff80, op=<optimized
out>) at ../../../../../servers/slapd/slapi/slapi_overlay.c:631
#7  slapi_op_func (op=0x7fffe2c9fff0, rs=0x7fffe2c9ff80) at
../../../../../servers/slapd/slapi/slapi_overlay.c:556
#8  0x00005555555ff18a in overlay_op_walk (op=op@entry=0x7fffe2c9fff0,
rs=0x7fffe2c9ff80, which=op_search, oi=0x5555559e5680, on=0x5555559e43a0)
at ../../../../servers/slapd/backover.c:661
#9  0x00005555555ff31b in over_op_func (op=0x7fffe2c9fff0, rs=<optimized
out>, which=<optimized out>) at ../../../../servers/slapd/backover.c:723
#10 0x00007ffff1c4a45b in syncprov_findbase (op=op@entry=0x555555eeff60,
fc=fc@entry=0x7fffe2ca0290) at syncprov.c:465
#11 0x00007ffff1c4cd87 in syncprov_op_search (op=0x555555eeff60,
rs=0x7fffe2ca1a50) at syncprov.c:2461
#12 0x00005555555ff18a in overlay_op_walk (op=op@entry=0x555555eeff60,
rs=rs@entry=0x7fffe2ca1a50, which=which@entry=op_search,
oi=0x5555559e5680, on=0x5555559bfbe0) at
../../../../servers/slapd/backover.c:661
#13 0x00007ffff63d3086 in slapi_op_func (rs=0x7fffe2ca1a50, op=<optimized
out>) at ../../../../../servers/slapd/slapi/slapi_overlay.c:647
#14 slapi_op_func (op=0x555555eeff60, rs=0x7fffe2ca1a50) at
../../../../../servers/slapd/slapi/slapi_overlay.c:556
#15 0x00005555555ff18a in overlay_op_walk (op=op@entry=0x555555eeff60,
rs=0x7fffe2ca1a50, which=op_search, oi=0x5555559e5680, on=0x5555559e43a0)
at ../../../../servers/slapd/backover.c:661
#16 0x00005555555ff31b in over_op_func (op=0x555555eeff60, rs=<optimized
out>, which=<optimized out>) at ../../../../servers/slapd/backover.c:723
#17 0x0000555555594641 in fe_op_search (op=0x555555eeff60,
rs=0x7fffe2ca1a50) at ../../../../servers/slapd/search.c:402
#18 0x0000555555593f06 in do_search (op=0x555555eeff60, rs=0x7fffe2ca1a50)
at ../../../../servers/slapd/search.c:247
#19 0x0000555555591961 in connection_operation
(ctx=ctx@entry=0x7fffe2ca1ba0, arg_v=arg_v@entry=0x555555eeff60) at
../../../../servers/slapd/connection.c:1150
#20 0x0000555555591c84 in connection_read_thread (ctx=0x7fffe2ca1ba0,
argv=<optimized out>) at ../../../../servers/slapd/connection.c:1286 #21
0x00007ffff7b9dff3 in ?? () from
/usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#22 0x00007ffff5d90b50 in start_thread (arg=<optimized out>) at
pthread_create.c:304
#23 0x00007ffff5adaa7d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#24 0x0000000000000000 in ?? ()
(gdb)

Valgrind doesn't turn up anything strange before the crash, so I guess it
comes down to design error in a relatively untested code path.

Tim