https://bugs.openldap.org/show_bug.cgi?id=9365
--- Comment #7 from Howard Chu <hyc(a)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.
--
You are receiving this mail because:
You are on the CC list for the issue.