The following patch fixes a memory leak in flow-cidr (flow-tools-0.68
/ Inter.netPH-1.3).
http://hhg.to/flow-cidr-memory-leak.diff
Bug description:
A memory leak occurs in the original version when filtering by src/dst
ipblock (option -i or -I) because a new patricia tree is created in
each
s:
FreeBSD aspen.invision.net 6.2-RELEASE FreeBSD 6.2-RELEASE #0: Tue Jan
23 11:50:47 EST 2007
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/aspen.invision.net
amd64
)
I saw some stuff about a possible memory leak on this list from last
January - was this confirmed or has nobody had a chance to debug thi
that huge memory usage is memory leak or I do something wrong ?
Thanks.
___
Flow-tools mailing list
[EMAIL PROTECTED]
http://mailman.splintered.net/mailman/listinfo/flow-tools
>
>
> My starting line for flow-capture is:
>
> /usr/local/bin/flow-capture -p /var/run/flow-capture.pid -n 287 -N 0 -w
> /var/log/netflows/ -S 5 /127.0.0.1/8899
>
> Is that huge memory usage is memory leak or I do something wrong ?
There could be a 64-bit problem. O
ox doesn't exhibit this issue.
If you care to look into this, I can provide access to the box in
question. If not, I'll might eventually figure it out.
I'm not at the point of caring about a memory leak. When I get there, I
can run it through valgrind.
Thanks,
Mark
O
Hi!
I have a server which flow-capture is set on.
Through time he strongly occupies memory.
Noticed it only on amd64
FreeBSD test.com 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Mon Feb 25 01:12:23 EET
2008
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC amd64
/usr/local/bin/flow-capture -E60G -n287
ure.pid -n 287 -N 0 -w
/var/log/netflows/ -S 5 /127.0.0.1/8899
Is that huge memory usage is memory leak or I do something wrong ?
There could be a 64-bit problem. Our setup has some 32-bit collectors that
feed (among other things) a 64-bit cruncher. Building out the 64-bit
cruncher lead me
-capture under valgrind
(http://valgrind.org/docs/manual/quick-start.html#quick-start.intro)
This _can_ detect some memory leaks.
It would be helpful if you'll use flow-tools-0.68.4
http://flow-tools.googlecode.com/files/flow-tools-0.68.4.tar.bz2
and wll include lib/ftconfig.h file (wh
/* foreach flow */
while ((rec = ftio_read(ftio))) {
len = fmt_xfields_val(values, rec, &fo, opt->ft_mask, 1);
/* form SQL query and execute it */
if (len) {
strcpy (query, "INSERT INTO ");
strcat (query, db_table);
strcat (query, "(");
strcat (query,
Replying to Mark R.:
> Are there any known issues with flow-tools on 64-bit platforms? I'm
> trying to run 0.68 on FreeBSD 7.0/amd64 and running into some odd
> behavior with flow-capture and flow-fanout.
There is at least one known memory leak that only happens on 64-bit
F
On Wed, Feb 28, 2007 at 01:05:54PM -0500, Michael Graziano wrote:
> >
> > I'm seeing something similar. I happened to be doing a 'top' from the
> > command-line right after staring up several flow-captures. Was
> > surprised to see them start to take up 30-40% and higher CPU.
Are you using the "-
[EMAIL PROTECTED] wrote on 02/28/2007 12:19:10 PM:
> I was troubleshooting an unrelated problem on our netflow cruncher this
> morning and discovered flow-capture chewing up RAM/Swap (to the point
> where it allocated all the swap on the box and was less-than-politely
> killed for doing so).
>
>
- I've always attributed this
to "normal" startup tasks, since the CPU utilization settles down after
a few minutes but (at least in our case) the memory utilization keeps
growing.
Our setup is one flow-capture daemon which takes data from our edge
routers (5 routers, for a total of
>
> On Wed, Feb 28, 2007 at 01:05:54PM -0500, Michael Graziano wrote:
> > >
> > > I'm seeing something similar. I happened to be doing a 'top' from
> the
> > > command-line right after staring up several flow-captures. Was
> > > surprised to see them start to take up 30-40% and higher CPU.
>
> Ar
ovide access to the box in question.
If not, I'll might eventually figure it out.
I'm not at the point of caring about a memory leak. When I get there, I can
run it through valgrind.
Thanks,
Mark
On Tue, 7 Oct 2008, Paul P Komkoff Jr wrote:
Replying to Mark R.:
Are there any know
(1):
Fix ip-destination-address/source-tag
Kurt Roeckx (1):
Use time_t instead of u_int32 in ftfile_mkpath and ftfile_pathname
Oleg Milaenko (1):
Use temporary time_t type variables to hold time values before displaying.
Otavio R. Piske (1):
Fix memory leak in flow-export
I was troubleshooting an unrelated problem on our netflow cruncher this
morning and discovered flow-capture chewing up RAM/Swap (to the point
where it allocated all the swap on the box and was less-than-politely
killed for doing so).
This is the first time I've caught flow-capture being killed for
17 matches
Mail list logo
