Interesting things to look for in the current 3.0 code ...

Peter Van Epp vanepp at sfu.ca
Fri Aug 17 10:31:21 EDT 2007


On Fri, Aug 17, 2007 at 01:54:03AM -0400, Carter Bullard wrote:
> Hey Peter,
> Well my leaks are not real, at least on my Mac, or on the 64-bit  
> intel machines,
> but my traffic loads are not really high, so I could have a very slow  
> memory issue.
> I'll try to replicate this tomorrow on some other hardware that I  
> have.  I did make
> some significant changes just now, that could affect both the  
> threaded and non
> threaded versions.  I changed the way we assign timeout values to  
> each flow.  It
> was possible, although it appeared highly unlikely, that individual  
> flows may
> try to use idle timeouts in the 1000's of seconds (this maybe your  
> old timestamp
> issue, but no promises) or possibly 0, which could put them in a bin  
> that
> may never time out (except when a matching packet hits that cache  
> then it
> would come back into the system).  well anyway, I limited the range  
> of timeout
> values, and possibly that could have an effect.  I've just now uploaded
> new argus and clients.
> 
> I'm going to let argus run all night on my mac running under  
> mallocdebug, which
> is not a bad program.  At least it showed me that I leaked 32 bytes,  
> but thats it so
> far ;o)
> 
> Carter
> 

	Mine look pretty real but may be just my machine :-). Yesterday's
argus without threads or user data:

ps auxwwww | grep argus
root      6698  1.5 96.6 4479328 3802756 ?     DLs  Aug16  12:11 argus -dJR -P 560 -i eth0 -i eth1 -m -F /scratch/argus.conf

and ra on the Mac isn't getting any data. I'm just about to try the new argus
and clients and see what happens.

Peter Van Epp / Operations and Technical Support 
Simon Fraser University, Burnaby, B.C. Canada




More information about the argus mailing list