[ARGUS] Another Core Dump

[Peter Van Epp]

On Tue, Apr 13, 2004 at 10:49:01PM -0500, eric wrote:
> I finally managed to witness our collector core today.
> 
> #0  0x8052918 in free ()
> (gdb) bt
> #0  0x8052918 in free ()
> #1  0x58 in ?? ()
> #2  0x804f632 in free ()
> #3  0x805272c in free ()
> #4  0x804ebe6 in free ()
> #5  0x804e32b in free ()
> #6  0x804ad6f in free ()
> #7  0x804a14e in free ()
> 
> However, when I run argus from gdb it doesn't die off.
> 
> Argh!

	Time for symbols :-). In the argus source directory

touch .devel
./configure
make clean 
make

	That will set the compiler -g flag and give gdb a symbol table. Then
you can do a where from gdb in the core and it will give you routine names 
and more importantly parameters being passed to the calls (maybe :-)) which
may tell Carter whats happening during times of crisis. Note the removal of
optimization with -g may slow argus down somewhat and you may lose packets
even during normal times. I suspect you may find a port scan or scans is the
source of the problem. A expect a port scan is going to create new flows at
a high rate and likely cause the most strain. Does the ra data just before
the crash show anything interesting (or the same general kinds of things before
every crash?) that too may give a clue to whats going on.

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