Interesting.  Two thoughts...

1. dns cache is corrupted.  Delete it (dnsCache.db, probably in
/usr/share/ntop or wherever you ./configure --prefix= told it to go.

2. Something unexpected/unhandled in the DNS packets.  In globals-defines.h,
there is a DNS_SNIFF_DEBUG option - enable it.  It will generate a lot more
log entries showing what's being sniffed out of the dns packets.

Also, you forgot to do the bt full under gdb - that's the key one, as it
dumps the data elements and local variables from each level of the call
stack.

-----Burton

> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of
> Steven Fowle
> Sent: Wednesday, April 28, 2004 6:51 AM
> To: [EMAIL PROTECTED]
> Subject: [Ntop] Re: ntop segfaults with high traffic
>
>
> Thanks for the response. Here is the information you asked for.
>
> Steve
>
> 1. ntop only stays running for a few minutes.
>
> 2.Here are the log messages running with --trace-level 6
>
> Apr 26 14:00:25 NTOP kernel: request_module[net-pf-10]: fork failed,
> errno 1
> Apr 26 14:16:15 NTOP kernel: request_module[net-pf-10]: fork failed,
> errno 1
>
> 3. Here is what I got from running ntop in gdb
>
> Mon 26 Apr 2004 02:20:04 PM EDT [MSGID0325854] [util:5718]
> CMPFCTN_DEBUG: setResolvedName(0x0dfcca48) 0  -> 19 129.100.74.79
> - hash.c(1169)
> Mon 26 Apr 2004 02:20:04 PM EDT [MSGID0325854] [util:5718]
> CMPFCTN_DEBUG: setResolvedName(0x0dfcf0e0) 0  -> 19
> 212.107.32.239 - hash.c(1169)
> Mon 26 Apr 2004 02:20:04 PM EDT [MSGID0325854] [util:5718]
> CMPFCTN_DEBUG: setResolvedName(0x0dfd1930) 0  -> 19 213.37.12.48
> - hash.c(1169)
> Mon 26 Apr 2004 02:20:04 PM EDT [MSGID0325854] [util:5718]
> CMPFCTN_DEBUG: setResolvedName(0x0dfd44d0) 0  -> 19 158.43.128.72
> - hash.c(1169)
> Mon 26 Apr 2004 02:20:04 PM EDT [MSGID0325854] [util:5718]
> CMPFCTN_DEBUG: setResolvedName(0x0dfd6e40) 0  -> 19 202.248.37.98
> - hash.c(1169)
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 1167272384 (LWP 13932)]
> 0x414245ae in get_elem (size=84, av_table=0x84c41c4,
> av_count=0x84c41c0) at falloc.c:343
> 343           av_table[index] = av_table[index+1];
> (gdb) thread
> [Current thread is 8 (Thread 1167272384 (LWP 13932))]
> (gdb) list
> 338       /* Ok, save that element and move all others up one. */
> 339       val = av_table[index];
> 340       *av_count -= 1;
> 341       while (index < *av_count)
> 342         {
> 343           av_table[index] = av_table[index+1];
> 344           index++;
> 345         }
> 346
> 347       return val;
> (gdb) info stack
> #0  0x414245ae in get_elem (size=84, av_table=0x84c41c4,
> av_count=0x84c41c0) at falloc.c:343
> #1  0x41424016 in _gdbm_alloc (dbf=0x808a0f0, num_bytes=84) at
> falloc.c:70
> #2  0x41422d6d in gdbm_store (dbf=0x808a0f0, key={dptr = 0x459269ec
> "3331933886", dsize = 11}, content=
>       {dptr = 0x4592699c "ecardview.hallmark.com", dsize = 73},
> flags=1) at gdbmstore.c:124
> #3  0x400df7c0 in ntop_gdbm_store () from /usr/lib/libntop-3.0.so
> #4  0x400d12d3 in processDNSPacket () from /usr/lib/libntop-3.0.so
> #5  0x400cadc0 in incrementUnknownProto () from /usr/lib/libntop-3.0.so
> #6  0x400ce128 in processPacket () from /usr/lib/libntop-3.0.so
> #7  0x400cb8b3 in queuePacket () from /usr/lib/libntop-3.0.so
> #8  0x414070ca in pcap_read () from /usr/lib/libpcap.so.0.6.2
> #9  0x4140863b in pcap_dispatch () from /usr/lib/libpcap.so.0.6.2
> #10 0x400c387c in pcapDispatch () from /usr/lib/libntop-3.0.so
> #11 0x412802b6 in start_thread () from /lib/tls/libpthread.so.0
>
>
> Message: 5
> Organization: Centro di Servizi per la rete di Ateneo - Pisa - Italy
> From: "Burton M. Strauss III"
> To:
> Subject: RE: [Ntop] ntop segfaults with high traffic (PR DCNT6SB)
> Date: Fri, 23 Apr 2004 12:05:55 -0500
> Reply-To: [EMAIL PROTECTED]
>
> There's nothing obviously weird... but obviously the PR is
> generated before
> the failure :-)
>
> 1. How long does it stay running (seconds, minutes, hours?)
>
> 2. What are the last log messages, esp if you run with --trace-level 6?
>
> 3. Can you run under gdb - instructions are in the docs/FAQ file - and
> capture the actual failure information?
>
> -----Burton
>
>
>
>
>

_______________________________________________
Ntop mailing list
[EMAIL PROTECTED]
http://listgateway.unipi.it/mailman/listinfo/ntop

Reply via email to