segfault at 000000000311c000 rip 000000000040fb46rsp 0000007fbffff830 error 4

[Peter Van Epp]

On Fri, May 15, 2009 at 02:18:16PM +0200, Gunnar Lindberg wrote:
> May 15 09:09:48 argv kernel: argus[18482] general protection rip:34e22696bd rsp:7fbfffe840 error:0
> 
> argus-3.0.1.beta.3/
> -rw-rw-r--   1 root root       0 May 15 07:13 .devel
> /bin/ls: .threads: No such file or directory
> 
> -rwxrwxr-x  1 lindberg lindberg   829883 May 15 08:43 argus
> -rw-r--r--  1 lindberg lindberg 41558016 May 15 09:09 core.18482
> 
> gdb argus-g.18482 core.18482
> #0  0x00000034e22696bd in _int_malloc () from /lib64/tls/libc.so.6
> 
> (gdb) where
> #0  0x00000034e22696bd in _int_malloc () from /lib64/tls/libc.so.6
> #1  0x00000034e226b420 in calloc () from /lib64/tls/libc.so.6
> #2  0x0000000000423994 in ArgusCalloc (nitems=5, bytes=4) at argus_util.c:1385
> #3  0x00000000004202a2 in ArgusUpdateAppState (model=0x659010, 
>     flowstr=0x6eee20, state=16 '\020') at ArgusApp.c:278
> #4  0x000000000040b00f in ArgusUpdateState (model=0x659010, flowstr=0x6eee20, 
>     state=16 '\020') at ArgusModeler.c:2443
> #5  0x000000000040a0ae in ArgusUpdateFlow (model=0x659010, flow=0x6eee20, 
>     state=16 '\020') at ArgusModeler.c:2068
> #6  0x0000000000408317 in ArgusProcessPacket (src=0x2a95786010, p=0x65bb12 "", 
>     length=171, tvp=0x7fbfffec60, type=-1) at ArgusModeler.c:1316
> #7  0x00000000004107db in ArgusEtherPacket (user=0x2a95786010 "", 
>     h=0x7fbfffece0, p=0x65bb12 "") at ArgusSource.c:716
> #8  0x00000034e2f04bff in ?? () from /usr/lib64/libpcap.so.0.8.3
> #9  0x0000000000413cd2 in ArgusGetPackets (src=0x2a95786010)
>     at ArgusSource.c:2093
> #10 0x0000000000404c77 in main (argc=1, argv=0x7fbffff5a8) at argus.c:535
> 
> common/argus_util.c
>    1362 void *
>    1363 ArgusCalloc (int nitems, int bytes)
>    1364 {
> ...
>    1385       retn = calloc (1, total + offset);
> ...
>    1437 }
> 
> 
> 	Gunnar Lindberg
> 

	This looks odd to me. Can you try running gdb and then do 

up
up   
print total
print offset

assuming I'm remembering my gdb correctly this should move the stack back to
ArgusCalloc and display the total and offset variable values. I don't think a 
request for 20 bytes (nitems=5 bytes=4 on the entry to ArgusCalloc) or 148 
bytes (if ARGUS_ALIGN is defined) should cause a segfault in the system alloc 
routine (which it seems to have) if those are the values that the system calloc 
got called with. This doesn't look like a bad parse requesting too much memory,
things look fine (assuming something bad hasn't happened to total and offset
of course) on the call to the system calloc and the problem occurs there.
	The argus on my adsl line hasn't segfaulted in the day or so it has been
up so far and I haven't heard anything from SFU who was reporting segfaults 
(as opposed to zero length data records before) on argus beta3 / clients beta.6
I also just realized I'm running argus beta.1 not beta.3 on my local sensor
as I was looking for the time stamp out of range errors Russell was reporting.
I'll move up to beta 3 and see if anything changes as SFU indicated the seg
faults started with beta.3.

Peter Van Epp