Looks like a new bug in argus

[Carter Bullard]

Hey Peter,
With those last results, lets take the ArgusOutputProcessor  
completely out of the
mix and see if we lose memory, if you don't mind.  So here I suspect  
that the
memory will be well behaved.

If you apply the patch below, we won't generate or  send any data to the
output processor, and so this should generate very little memory  
issues, at least
that would be the theory.  This is the patch:

2942a2943,2944
 >       model->ArgusTotalSends++;
 > /*
2946d2947
<
2960a2962
 > */



And below is the diff with the "-c" option so you can see what I'm  
suggesting.
Let that run for a little while, and see if the memory stays low.

Carter



*** argus-3.0.0/argus/ArgusModeler.c    2007-08-18 01:32:45.000000000  
-0400
--- argus-3.0.0.diff/argus/ArgusModeler.c       2007-08-19  
18:25:28.000000000 -0400
***************
*** 2940,2949 ****
            } while (frag != (struct ArgusFlowStruct *)flow- 
 >frag.start);
         }

         if (flow->canon.metric.src.pkts || flow- 
 >canon.metric.dst.pkts) {
            if ((flow->canon.trans.seqnum = model->ArgusSeqNum++) ==  
0xFFFFFFFF)
               flow->canon.trans.seqnum = model->ArgusSeqNum++;
-
            if ((argus = ArgusGenerateListRecord (model, flow,  
state)) != NULL) {
               flow->status |= ARGUS_RECORD_WRITTEN;
               model->ArgusTotalSends++;
--- 2940,2950 ----
            } while (frag != (struct ArgusFlowStruct *)flow- 
 >frag.start);
         }

+       model->ArgusTotalSends++;
+ /*
         if (flow->canon.metric.src.pkts || flow- 
 >canon.metric.dst.pkts) {
            if ((flow->canon.trans.seqnum = model->ArgusSeqNum++) ==  
0xFFFFFFFF)
               flow->canon.trans.seqnum = model->ArgusSeqNum++;
            if ((argus = ArgusGenerateListRecord (model, flow,  
state)) != NULL) {
               flow->status |= ARGUS_RECORD_WRITTEN;
               model->ArgusTotalSends++;
***************
*** 2958,2963 ****
--- 2959,2965 ----
            }
         } else
            model->ArgusTotalBadSends++;
+ */
      }

   #ifdef ARGUSDEBUG






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
>