[Bro] BRO valgrind test

Krishna M. Patchava KPatchava at facetime.com
Wed Jun 15 10:29:58 PDT 2005

Here is the valgrind log for bro.
I have just mentioned only the major memory leaks.

==11471== LEAK SUMMARY:
==11471==    definitely lost: 481728 bytes in 16476 blocks.
==11471==    indirectly lost: 30728880 bytes in 352127 blocks.
==11471==      possibly lost: 21299 bytes in 148 blocks.
==11471==    still reachable: 15977295 bytes in 252536 blocks.
==11471==         suppressed: 0 bytes in 0 blocks.

==11471== 25872460 (2184 direct, 25870276 indirect) bytes in 42 blocks
are definitely lost in loss record 467 of 547
==11471==    at 0x1B903407: operator new(unsigned)
==11471==    by 0x807792D:
DFA_Machine::StateSetToDFA_State(NFA_StatePList*, DFA_State*&,
EquivClass const*) (DFA.cc:629)
==11471==    by 0x807608A: DFA_State::ComputeXtion(int, DFA_Machine*)
==11471==    by 0x80FC32A: DFA_State::Xtion(int, DFA_Machine*)
==11471==    by 0x80FB141: RE_Match_State::Match(unsigned char const*,
int, bool, bool) (RE.cc:346)
==11471==    by 0x810AB6A: RuleMatcher::Match(RuleEndpointState*,
Rule::PatternType, unsigned char const*, int, bool, bool)
==11471==    by 0x80AE47F: Connection::Match(Rule::PatternType, unsigned
char const*, int, bool, bool, int) (Conn.h:208)
==11471==    by 0x8136FF0: TCP_Reassembler::BlockInserted(DataBlock*)
==11471==    by 0x80FDFB4: Reassembler::NewBlock(double, int, int,
unsigned char const*) (Reassem.cc:99)
==11471==    by 0x8137B14: TCP_Contents::DataSent(double, int, int,
unsigned char const*) (TCP_Contents.cc:335)
==11471==    by 0x813A008: TCP_Endpoint::DataSent(double, int, int,
unsigned char const*, IP_Hdr const*, tcphdr const*)
==11471==    by 0x8133FDB: TCP_Connection::NextPacket(double, int,
IP_Hdr const*, int, int, unsigned char const*&, int&, int&, pcap_pkthdr
const*, unsigned char const*, int) (TCP.cc:1191)

==11471== 1874712 (117120 direct, 1757592 indirect) bytes in 3660 blocks
are definitely lost in loss record 217 of 547
==11471==    at 0x1B903407: operator new(unsigned)
==11471==    by 0x80E209E: make_alternate(NFA_Machine*, NFA_Machine*)
==11471==    by 0x80FA8B1: Specific_RE_Matcher::CompileSet(charPList
const&, intList const&) (RE.cc:173)
==11471==    by 0x810A2DE:
RuleMatcher::BuildPatternSets(RuleHdrTest::PatternSetPList*, charPList
const&, intList const&) (RuleMatcher.cc:360)
==11471==    by 0x8109CF1: RuleMatcher::BuildRegEx(RuleHdrTest*,
charPList*, intList*) (RuleMatcher.cc:303)
==11471==    by 0x8109EC2: RuleMatcher::BuildRegEx(RuleHdrTest*,
charPList*, intList*) (RuleMatcher.cc:312)
==11471==    by 0x8109747: RuleMatcher::ReadFiles(charPList const&)
==11471==    by 0x804D234: main (main.cc:649)

-----Original Message-----
From: Robin Sommer [mailto:sommer at in.tum.de] 
Sent: Wednesday, June 15, 2005 12:30 PM
To: Vishwanathan Krishnamurthy
Cc: Bro List
Subject: Re: [Bro] BRO valgrind test

On Wed, Jun 15, 2005 at 10:25 +0530, Vishwanathan Krishnamurthy wrote:

> I ran valgrind against an instance of BRO. I found memory leaks
(refering to operator new())

Valgrind usually reports a couple of leaks in the script parser.
These are rather minor though as their total volume is small and
they only occur once during initialization.

However, if you see any leak reported during Bro's main processing
then that's a significant bug; every leak in the main loop may drive
Bro to memory exhaustion eventually. In this case, could you please
mail us the valgrind logs?



Robin Sommer * Room        01.08.055 * www.net.in.tum.de
TU Muenchen  * Phone (089) 289-18006 *  sommer at in.tum.de 
Bro mailing list
bro at bro-ids.org

More information about the Bro mailing list