[Bro] Memory leak output
liburdi.joshua at gmail.com
Mon Feb 2 12:07:59 PST 2015
Thanks for the reply. This particular Bro package was the stable 2.3.2
release with an additional TCP analyzer I am testing, but perftools
reports leaks with the stable release of 2.3.2 on its own. Some
additional data for you if you're interested:
Using a 1.7GB pcap file ...
perftools reported Bro 2.3.2 as having a leak of 1216 bytes in 8 objects
perftools reported Bro 2.3.2 plus my analyzer as having a leak of 1368
bytes in 9 objects
perftools reported git/master as having a leak of 5136 bytes in 78 objects
Running the top command in pprof for all runs resulted in 0.0MB shown.
All runs did not indicate where the objects were allocated from.
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) ...
On Mon, Feb 2, 2015 at 9:32 AM, Siwek, Jon <jsiwek at illinois.edu> wrote:
>> On Feb 1, 2015, at 2:34 PM, Josh Liburdi <liburdi.joshua at gmail.com> wrote:
>> Hey everyone,
>> I'm performing testing for memory leaks and am running into an
>> interesting perftools error message:
>> Thread finding failed with -1 errno=1
>> Could not find thread stacks. Will likely report false leak positives.
>> Have memory regions w/o callers: might report false leaks
>> Leak check net_run detected leaks of 1520 bytes in 10 objects
>> The 1 largest leaks:
>> Leak of 1520 bytes in 10 objects allocated from:
>> If the preceding stack traces are not enough to find the leaks, try
>> running THIS shell command:
>> pprof bro "/tmp/bro.3885.net_run-end.heap" --inuse_objects --lines
>> --heapcheck --edgefraction=1e-10 --nodefraction=1e-10 --gv
>> I can't tell what caused this error. Has anyone seen this before?
> Running the `pprof` command that it gives (I usually omit —gv because I don’t have/want ghostview output) will help determine the cause. The `top` command in pprof usually gives me enough info to spot problems.
>> is my first time running a memory leak test and this is happening for
>> all trace files, so I'm not sure if this is normal (guessing no).
> No, not normal, but if you happened to be testing git/master there was a recent leak introduced; now fixed:
> - Jon
More information about the Bro