https://bugs.openldap.org/show_bug.cgi?id=9365
--- Comment #7 from Howard Chu <[email protected]> --- (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.
