By the way, rlm_checkval meets in most cases losses ==8528== 200448 bytes in 783 blocks are definitely lost in loss record 178 of 190 ... ==8528== by 0x1BB83E41: regcomp (in /lib/tls/libc-2.3.2.so) ==8528== by 0x1D310FC3: do_checkval (rlm_checkval.c:275) ... ==8528== 60416 bytes in 59 blocks are possibly lost in loss record 162 of 190 ... ==8528== by 0x1BB88BF0: regexec (in /lib/tls/libc-2.3.2.so) ==8528== by 0x1D310FF4: do_checkval (rlm_checkval.c:281) ... ==8528== 55800 bytes in 15 blocks are possibly lost in loss record 159 of 190 ... ==8528== by 0x1BB83EBF: regcomp (in /lib/tls/libc-2.3.2.so) ==8528== by 0x1D310FC3: do_checkval (rlm_checkval.c:275) ... ==8528== 22320 bytes in 6 blocks are possibly lost in loss record 151 of 190 ... ==8528== by 0x1BB83EBF: regcomp (in /lib/tls/libc-2.3.2.so) ==8528== by 0x1D310FC3: do_checkval (rlm_checkval.c:275) ... etc.
"Dmitry V. Pleganoff" <dimple@mail.primorye.ru> wrote:
By the way, rlm_checkval meets in most cases losses
Please re-run valgrind after re-building, and post any leaks. They should be fixed, too. I've run valgrind on the CVS head, but I don't have every possible code path tested, so I can't find all of the leaks. Alan DeKok.
participants (2)
-
Alan DeKok -
Dmitry V. Pleganoff