Hi,
While performing a longevity test on bro, I see bro memory consumption going up. I ran valgrind on a large pcap. After analyzing the valgrind logs, I came across some instance where I think bro is leaking. I’ve enclosed my analysis below. I’d appreciate if someone more familiar in these areas comments on analysis i.e. if my suspicions are correct or not. Thanks.
Dk.
Bro Version: 2.4.1
Valgrind Stack:
Hello D,
thank you for your analysis. I took a look at the leaks you found and
think the first two are indeed memory leaks; this is fixed in
a156f2b4e63d64b3cbe888e8cb88f1c05d3e7b86 (see
[BIT-1633] - Bro Tracker to track the merge
process).
I think the last one is not a memory leak:
3) NFA_State::DeepCopy() (NFA.cc:58)
Valgrind Stack:
---------------
96 bytes in 1 blocks are possibly lost in loss record 3,374 of 6,072
at 0x4C2B0E0: operator new(unsigned long)
by 0x5CEDB0: NFA_State::DeepCopy() (NFA.cc:58)
by 0x5CF305: NFA_Machine::DuplicateMachine() (NFA.cc:210)
by 0x5CF63B: NFA_Machine::MakeRepl(int, int) (NFA.cc:252)
by 0x53B648: RE_parse() (re-parse.y:76)
by 0x5DD449: Specific_RE_Matcher::CompileSet(charPList const&,
ptr_compat_intList const&) (RE.cc:142)Comments:
---------
- New NFA_State allocate in DeepCopy function is not freed.
- The pointer is saved in 'mark' member variable. However, in
ClearMarks function
the member is clear is simply cleared without freeing the pointer.
DeepCopy is only called when creating a new NFA_Machine in
DuplicateMachine. The pointer of the DeepCopy is stored in the first_state
member of NFA_Machine, which is Unref'd in NFA.cc:160. So I think this
seems fine.
Thanks again,
Johanna