Memory leak in sumstats (probably)

Description

At the moment, the core/leaks/basic-cluster.bro always fails; the gprof output is attached. Only the master node leaks memory, the two worker nodes are fine.

From the gprof output, it looks like an increment operation is somehow triggering a memory leak.

Robin and me tried to dig through this for quite some time. From our current understanding it looks like the memory leak is (indirectly) caused by an increment operation in a function that is called by an event that is received through remoteserialization.

The closest we were able to track the leak to is line 249 of scripts/base/frameworks/sumstats/cluster.bro:

Commenting out this line "fixes" the memory leak (and probably renders the sumstat framework inoperable); however we were not able to track it further to the exact cause; replacing the increment with an equivalent done_with[uid] = done_with[uid]+1; did not solve the problem.

Environment

None

Activity

Show:
Jon Siwek
August 19, 2013, 9:27 PM

I was looking at this a bit last week, but haven't got back to it yet. My current guess is it's something to do with the Trigger/StateAccess/NotifierRegistry code. The sumstats scripts have a couple places where the condition of a when() block depends on done_with[uid] so places that do ++done_with[uid] trigger creation of a new value that's reported as leaked possibly because that value is being held by the trigger-notification code or because Bro terminates before that trigger-notification code has a chance to run and release resources.

Jon Siwek
August 21, 2013, 7:35 PM

Fix in topic/jsiwek/when-leak.

Merged

Assignee

Robin Sommer

Reporter

Johanna Amann

Labels

External issue ID

None

Components

Fix versions

Affects versions

Priority

High
Configure