[Bro] Memory leak output
liburdi.joshua at gmail.com
Mon Feb 2 13:26:38 PST 2015
Addtionally, my Bro debug.log is empty.
On Mon, Feb 2, 2015 at 1:25 PM, Josh Liburdi <liburdi.joshua at gmail.com> wrote:
> That's odd, I am using the configuration referenced on the Finding
> Memory Leaks page: ./configure --enable-debug --enable-perftools
> I tried your configuration as well and receive the same results
> (gperftools reports memory leaks but can't find thread stacks,
> valgrind finds no memory leaks whatsoever). There must be something
> wrong with one of my installations.
> On Mon, Feb 2, 2015 at 12:41 PM, Siwek, Jon <jsiwek at illinois.edu> wrote:
>>> On Feb 2, 2015, at 2:07 PM, Josh Liburdi <liburdi.joshua at gmail.com> wrote:
>>> I also ran all packages (standard 2.3.2, 2.3.2 with my analyzer, and
>>> git/master) through valgrind and that found zero leaks in all runs. Do
>>> you have an opinion on which tool (perftools or valgrind) is more
>>> "accurate" with regard to reporting leaks? I'm not sure why perftools
>>> is not finding thread stacks (unless they simply don't exist and the
>>> reported leaks are false positives) ...
>> How did you configure/build Bro? My leak check configuration is
>> ./configure --enable-debug --enable-perftools-debug
>> Regarding accuracy, I haven’t noticed much difference between valgrind and gperftools. Sometimes I prefer valgrind just to also check for other memory errors (e.g. invalid read/write, using uninitialized). AddressSanitizer is also a nice tool.
>> However, unless you’re using a suppression file, valgrind should be reporting a lot of “leaks” in Bro’s initialization routines that aren’t really concerning. With gperftools, Bro has been instrumented to only check for leaks in the main I/O loop, so leaks it reports are usually always concerning.
>> - Jon
More information about the Bro