Looks like a new bug in argus

[Carter Bullard]

Hey Peter,
Well the output processor still gets the records and does the deletes.
But without any clients, it doesn't do the additional record copies  
needed
to support multiple clients.  Let me put in some additional code to  
remove
some of the complextity when there are no clients, so give me a few  
hours
to rip out some code.

Until then, why don't we try valgrind on your system.
http://valgrind.org/

Grab 3.2.3, and after you get it compiled and going, just do this with
an argus that does not go into daemon mode (ARGUS_DAEMON=no)

    valgrind ../bin/argus

and at some point, send it a -HUP, and it will spit out what it thinks
maybe wrong with memory.  There will be some bogus messages
about printf having uninitialized data, etc..., but these are bogus
errors, so not to worry about.

Carter


On Aug 19, 2007, at 5:56 PM, Peter Van Epp wrote:

> 	Looks like the leak isn't in argus output. This is from an argus
> started a few hours ago with no clients reading from it:
>
> ps auxwwww | grep argus
> root      8310  7.9 55.3 4337804 2178888 ?     DL   10:46  19:37  
> argus -JR -P 560 -i eth0 -i eth1 -U 512 -m -D1 -F /scratch/argus.conf
>
>
> Aug 19 10:43:26 hcids su: (to root) vanepp on /dev/pts/1
> Aug 19 10:46:11 hcids kernel: RING: succesfully allocated 0 KB  
> [tot_mem=12664896][order=12]
> Aug 19 10:46:11 hcids kernel: RING: allocated 10851 slots  
> [slot_len=1546][tot_mem=16777216]
> Aug 19 10:46:11 hcids kernel: RING: succesfully allocated 0 KB  
> [tot_mem=12664896][order=12]
> Aug 19 10:46:11 hcids kernel: RING: allocated 10851 slots  
> [slot_len=1546][tot_mem=16777216]
> Aug 19 11:15:36 hcids syslog-ng[3226]: STATS: dropped 0
> Aug 19 12:15:37 hcids syslog-ng[3226]: STATS: dropped 0
> Aug 19 13:15:37 hcids syslog-ng[3226]: STATS: dropped 0
> Aug 19 14:15:37 hcids syslog-ng[3226]: STATS: dropped 0
> Aug 19 14:48:41 hcids sshd[8642]: Accepted keyboard-interactive/pam  
> for vanepp from 142.58.1.234 port 55646 ssh2
>
> 	I'll poke at getting a bit more granularity (and arguslist mallocs  
> and
> frees) included in the debug output to see if I can figure out  
> where the leak
> is occurring. It may be useful to arrange a signal that will freeze  
> the argus
> and dump all the currently allocated block addresses to the debug  
> file so we
> can see if there are blocks in the list that aren't referenced.
>
> Peter Van Epp / Operations and Technical Support
> Simon Fraser University, Burnaby, B.C. Canada
>