Looks like a new bug in argus

[Peter Van Epp]

	OK, I sent it a HUP, but valgrind didn't return any output. I assume
that means it didn't see anything wrong?

==23554== Conditional jump or move depends on uninitialised value(s)
==23554==    at 0x405056C: strlen (mc_replace_strmem.c:246)
==23554==    by 0x1002CE2C: ArgusLog (argus_util.c:1637)
==23554==    by 0x1001A9A4: ArgusGetInterfaceStatus (ArgusSource.c:2014)
==23554==    by 0x10018AC4: ArgusGetPackets (ArgusSource.c:1627)
==23554==    by 0x10005798: main (argus.c:545)
  ArgusWarning: argus[23554]: 14 Apr 58 15:28:16.268867 ArgusGetInterfaceStatus: interface eth1 is up
  ArgusWarning: argus[23554]: 14 Apr 58 15:28:16.268867 ArgusGetInterfaceStatus: interface eth0 is up
hcids:/scratch # !ps
ps auxwwww | grep argus
root     23554 94.6  6.7 302424 267080 pts/0   RL   16:47   4:37 valgrind argus -JR -P 560 -i eth0 -i eth1 -U 512 -m -F /scratch/argus.conf
root     23556  0.0  0.0   3132   832 pts/0    S+   16:51   0:00 grep argus
hcids:/scratch # ps auxwwww | grep argus
root     23554 94.7  6.8 304904 269336 pts/0   RL   16:47   4:41 valgrind argus -JR -P 560 -i eth0 -i eth1 -U 512 -m -F /scratch/argus.conf
root     23558  0.0  0.0   3132   832 pts/0    S+   16:52   0:00 grep argus
hcids:/scratch # ps auxwwww | grep argus
root     23554 94.9  6.9 309912 274240 pts/0   RL   16:47   4:49 valgrind argus -JR -P 560 -i eth0 -i eth1 -U 512 -m -F /scratch/argus.conf
root     23560  0.0  0.0   3132   832 pts/0    S+   16:52   0:00 grep argus
hcids:/scratch # ps auxwwww | grep argus
root     23554 96.7  9.8 423336 387688 pts/0   RL   16:47   7:49 valgrind argus -JR -P 560 -i eth0 -i eth1 -U 512 -m -F /scratch/argus.conf
root     23562  0.0  0.0   3132   832 pts/0    S+   16:55   0:00 grep argus
hcids:/scratch # ps auxwwww | grep argus
root     23554 97.2 21.1 868248 832748 pts/0   RL   16:47  19:14 valgrind argus -JR -P 560 -i eth0 -i eth1 -U 512 -m -F /scratch/argus.conf
root     23634  0.0  0.0   3132   828 pts/0    R+   17:06   0:00 grep argus
hcids:/scratch # ps auxwwww | grep argus
root     23554 98.9 61.3 2452280 2416176 pts/0 RL   16:47  61:30 valgrind argus -JR -P 560 -i eth0 -i eth1 -U 512 -m -F /scratch/argus.conf
root     23700  0.0  0.0   3132   832 pts/0    S+   17:49   0:00 grep argus
hcids:/scratch # kill -HUP 23554
hcids:/scratch # argus: Time 3747.371202 Flows 992025    Closed 0         Sends 1184756   BSends 0        Updates 29300596 Cache 28241033
eth1
    Total Pkts 16134409  Rate 4305.527296
eth0
    Total Pkts 13098619  Rate 3495.415398

hcids:/scratch # !ps
ps auxwwww | grep argus
root     23554 99.0 61.6 2462524 2427332 pts/0 RL   16:47  67:13 valgrind argus -JR -P 560 -i eth0 -i eth1 -U 512 -m -F /scratch/argus.conf
root     23702  0.0  0.0   3132   832 pts/0    S+   17:54   0:00 grep argus
hcids:/scratch #

	Looks like I wasn't patient enough :-). What I think is valgrind has
just reported:

hcids:/scratch # ==23554==
==23554== ERROR SUMMARY: 808 errors from 54 contexts (suppressed: 2 from 1)
==23554== malloc/free: in use at exit: 3,238 bytes in 12 blocks.
==23554== malloc/free: 2,394,332 allocs, 2,394,320 frees, 1,722,063,348 bytes allocated.
==23554== For counts of detected errors, rerun with: -v
==23554== searching for pointers to 12 not-freed blocks.
==23554== checked 34,962,672 bytes.
==23554==
==23554== LEAK SUMMARY:
==23554==    definitely lost: 1,351 bytes in 5 blocks.
==23554==      possibly lost: 0 bytes in 0 blocks.
==23554==    still reachable: 1,887 bytes in 7 blocks.
==23554==         suppressed: 0 bytes in 0 blocks.
==23554== Rerun with --leak-check=full to see details of leaked memory.

[1]+  Done                    valgrind argus -JR -P 560 -i eth0 -i eth1 -U 512 -m -F /scratch/argus.conf

	I'll rerun with --leak-check=full as it suggests however I don't think
this is likely our entire problem (it isn't large enough). Is the 0 closed
flows due to the output process being disabled or is that part of the problem
(i.e. we are validly holding memory that has been correctly allocated when 
we shouldn't be, because the flow should have closed and the memory gotten 
deallocated). I don't think that valgrind will find that type of error.
	If I'm reading this correctly it thinks at exit we had 1.7 gigabytes
of memory correctly allocated. That sounds way to large to me for the number
of open flows we should be seeing (although I'm comparing to 2.0.6 which may
not be a valid comparision).

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