[Bro] Memory leak output

[Josh Liburdi]

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
> --enable-perftools-debug
>
> 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