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.
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.
Fix in topic/jsiwek/when-leak.