https://bugs.openldap.org/show_bug.cgi?id=9365
--- Comment #7 from Howard Chu hyc@openldap.org --- (In reply to Michael Ströder from comment #6)
I've retested with latest RE24 with the commit and the output still contains this:
==898== 47,104 bytes in 23 blocks are indirectly lost in loss record 95 of 96 ==898== at 0x483BB65: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==898== by 0x49FA5F5: build_trtable (/usr/src/debug/glibc-2.32-1.1.x86_64/posix/regexec.c:3403)
For the tests I've disabled background jobs and all other replicas and I've sent simple bind operation 59 times. So to me the count of 23 does not seem to correlate with the number of operations.
There's nothing else in this output that indicates a leak. If this is just some regex-internal structure that needs 23 allocs to init itself, then we have to look elsewhere. Probably you'll need to enable the consumers and generate some activity on the provider.