Argus Memory Problem?

[Carter Bullard]

Well, I spoke too soon.  I just sent mail to Mark P. that
he was the only one getting seg faults.  OK, I'm on it.
Looks like its having problems in ArgusCalloc().
So there was a return NULL problem probably, but, .....,
it looks like the most plausible cause was that you ran
out of memory.  malloc() returned NULL.  I blew up.

Russell mentioned that he was running out of swap space,
and I think someone else had that problem.  Memory leak?
Anyone check the size of their processes when there was
the problem?

Carter

-----Original Message-----
From: owner-argus at lists.andrew.cmu.edu
[mailto:owner-argus at lists.andrew.cmu.edu]On Behalf Of Peter Van Epp
Sent: Friday, September 29, 2000 10:58 AM
To: argus
Subject: Re: pthreads on FreeBSD


	It appears to have run without time stamp corruption up til 2 AM:

demoa# !! | grep -v "^29"
ra -r argus.log -c -n | grep -v "^28" | grep -v "^29"
demoa#

when it crashed on something:

demoa# gdb argus_bpf argus_bpf.core
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd"...
Core was generated by `argus_bpf'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libm.so.2...done.
Reading symbols from /usr/lib/libc.so.4...done.
Reading symbols from /usr/libexec/ld-elf.so.1...done.
#0  0x28115fba in bzero () from /usr/lib/libc.so.4
(gdb) where
#0  0x28115fba in bzero () from /usr/lib/libc.so.4
#1  0x104 in ?? ()
#2  0x804a2b9 in ArgusNewFlow () at ./ArgusModeler.c:374
#3  0x804a1f9 in ArgusProcessPacket (ep=0x80777e0, length=62, tvp=0x81c15f4)
    at ./ArgusModeler.c:323
#4  0x804d596 in ArgusEtherPacket (user=0x0, h=0x81c15f4, p=0x81c1606 "\b")
    at ./ArgusSource.c:350
#5  0x8056110 in pcap_read ()
#6  0x804dbfa in ArgusGetPackets () at ./ArgusSource.c:703
#7  0x8049d4b in ArgusLoop () at ./argus.c:267
#8  0x8049c4e in main (argc=4, argv=0xbfbffbf0) at ./argus.c:189
#9  0x80496fd in _start ()
(gdb) print ep
No symbol "ep" in current context.
(gdb) up
#1  0x104 in ?? ()
(gdb) up
#2  0x804a2b9 in ArgusNewFlow () at ./ArgusModeler.c:374
374           if ((retn = (struct ArgusFlowStruct *) ArgusCalloc (1, sizeof
(struct ArgusFlowStruct))) != NULL) {
(gdb) print ep
No symbol "ep" in current context.
(gdb) up
#3  0x804a1f9 in ArgusProcessPacket (ep=0x80777e0, length=62, tvp=0x81c15f4)
    at ./ArgusModeler.c:323
323                          flow = ArgusNewFlow();
(gdb) print ep
$1 = (struct ether_header *) 0x80777e0
(gdb) print *ep
$2 = {ether_dhost = {ether_addr_octet = "\b\000 \233k>"}, ether_shost = {
    ether_addr_octet = "\000`c\002RB"}, ether_type = 2048}
(gdb) q

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


>
> Hey Neil,
>    I ripped out all the threads in argus and
> made the components big old processes.  Primarily
> to support flex/bison based filtering in each
> one.  It was easier to do that than fixing the
> problem we were having.  Still, thanks for the
> heads up!!!
>
>    We may have found the bogus timestamp problem,
> as the new version of 2.0.0j is still(?) running
> at Peter's without a time glitch.  I was convinced
> the problem was caused by everybody and thing
> other than my inability to program a computer.  But
> reality won out in the end ;o)
>
> Carter
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20000929/a4d81031/attachment.html>