[Bro] memory q.

[Dk Jack]

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

1) PersistenceSerializer::CheckTimestamp (PersistenceSerializer.cc:102)

   Valgrind Stack:
   ---------------
   8 bytes in 1 blocks are definitely lost in loss record 32 of 6,072
   at 0x4C2AB80: malloc
   by 0x5DA094: PersistenceSerializer::CheckTimestamp(char const*)
(PersistenceSerializer.cc:102)
   by 0x5DA10D: PersistenceSerializer::CheckForFile(UnserialInfo*, char
const*, bool) (PersistenceSerializer.cc:121)
   by 0x5DA2AA: PersistenceSerializer::ReadAll(bool, bool)
(PersistenceSerializer.cc:157)
   by 0x52F857: main (main.cc:1068)

   Comments:
   ---------
    - CheckTimestamp function allocats memory for 'time_t'. This is then
inserted into
      files dictionary. This memory never seems to be freed.
    - The files dictionary is of type PDict i.e Dictionary. The Dictionary
destructor seems
      to be deleting/freeing the memory for key and values. However, this
requires the
      Dictionary user to set the delete_function which will be called to
free the value pointer.
    - Since the delete_function is never set (using SetDeleteFunc), the
time_t structures are
      never freed.

2) NFA_State::EpsilonClosure() (NFA.cc:82)

   Valgrind Stack:
   ---------------
   24 bytes in 1 blocks are possibly lost in loss record 582 of 6,072
   at 0x4C2B0E0: operator new(unsigned long)
   by 0x5CEEC4: NFA_State::EpsilonClosure() (NFA.cc:82)
   by 0x5CF955: epsilon_closure(NFA_StatePList*) (NFA.cc:324)
   by 0x56B939: DFA_State::ComputeXtion(int, DFA_Machine*) (DFA.cc:93)
   by 0x5DDB59: Xtion (DFA.h:160)
   by 0x5DDB59: RE_Match_State::Match(unsigned char const*, int, bool,
bool, bool) (RE.cc:318)

   Comments:
   ---------
    - In function EpsilonClosure, NFA_state_list object is instantiated.
This object never
      seems to be freed.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20160617/959fbfb2/attachment.html