https://bugzilla.balabit.com/show_bug.cgi?id=257 --- Comment #8 from Evan Rempel <erempel@uvic.ca> 2013-11-02 19:29:34 --- (In reply to comment #7)
(In reply to comment #6)
Created an attachment (id=85) --> (https://bugzilla.balabit.com/attachment.cgi?id=85) [details] [details] valgrind --leak-check=full --show-reachable=yes --verbose
here is the valgrind --leak-check=full --show-reachable=yes --verbose
on a syslog-ng compiled with -ggdb3 -O3
Hrm. How many reloads was this? Valgrind only reports about 16-17k leaked memory which isn't all that much... though... syslog-ng is using the slice allocator, which tends to confuse valgrind at times. I'm sorry I forgot this earlier, but would it be possible to re-run the test with G_SLICE=always-malloc set in the environment too? And the more reloads the better.
This was 5 reloads. I have to wait 1 minute between reloads because syslog-ng locks up when reloaded too fast inside of valgrind. I thought that ==21474== LEAK SUMMARY: ==21474== definitely lost: 5,517 bytes in 51 blocks ==21474== indirectly lost: 2,183,888 bytes in 61,461 blocks ==21474== possibly lost: 2,455,423 bytes in 45,187 blocks ==21474== still reachable: 140,643 bytes in 3,064 blocks ==21474== suppressed: 0 bytes in 0 blocks indicated that there was at least 2MB lost. I'm not proficient at reading valgrind output though. I'll rerun with the G_SLICE=always-malloc -- Configure bugmail: https://bugzilla.balabit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.