That message is not - necessarily - indicative of a problem. (code is in hash.c
around 840).
What it's doing is walking the list to find the right entry.
while(list != NULL) {
if(list->idx == hostIdx) {
allRight = 1;
break;
} else {
prevList = list;
list = list->next;
}
}
There could be other reasons (?) for this. But I'm suspicious because of the
proximity.
Have you tried the patch? If you ARE getting the out of memory problem, then that
could explain it. If you're not, then the
problem is going to take another approach to get the data to figure out what's up...
-----Burton
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Michael Baird
Sent: Monday, April 29, 2002 11:35 AM
To: [EMAIL PROTECTED]
Subject: RE: [Ntop] Ntop 29-4-02 snapshot
Burton, I get bunch of these messages as well along the way, maybe this
could be related.
9/Apr/2002 12:37:01 ERROR: purgeHostIdx(1,32746) failed [host not found]
29/Apr/2002 12:37:01 ERROR: purgeHostIdx(1,32747) failed [host not
found]
29/Apr/2002 12:37:01 ERROR: purgeHostIdx(1,32748) failed [host not
found]
29/Apr/2002 12:37:01 ERROR: purgeHostIdx(1,32749) failed [host not
found]
29/Apr/2002 12:37:01 ERROR: purgeHostIdx(1,32750) failed [host not
found]
29/Apr/2002 12:37:01 ERROR: purgeHostIdx(1,32751) failed [host not
found]
29/Apr/2002 12:37:01 ERROR: purgeHostIdx(1,32752) failed [host not
found]
29/Apr/2002 12:37:01 ERROR: purgeHostIdx(1,32753) failed [host not
found]
29/Apr/2002 12:37:01 ERROR: purgeHostIdx(1,32754) failed [host not
found]
29/Apr/2002 12:37:01 ERROR: purgeHostIdx(1,32755) failed [host not
found]
29/Apr/2002 12:37:01 ERROR: purgeHostIdx(1,32756) failed [host not
found]
29/Apr/2002 12:37:01 ERROR: purgeHostIdx(1,32757) failed [host not
found]
29/Apr/2002 12:37:01 ERROR: purgeHostIdx(1,32758) failed [host not
found]
29/Apr/2002 12:37:01 ERROR: purgeHostIdx(1,32759) failed [host not
found]
29/Apr/2002 12:37:01 ERROR: purgeHostIdx(1,32760) failed [host not
found]
29/Apr/2002 12:37:01 ERROR: purgeHostIdx(1,32761) failed [host not
found]
29/Apr/2002 12:37:01 ERROR: purgeHostIdx(1,32762) failed [host not
found]
29/Apr/2002 12:37:01 ERROR: purgeHostIdx(1,32763) failed [host not
found]
29/Apr/2002 12:37:01 ERROR: purgeHostIdx(1,32764) failed [host not
found]
29/Apr/2002 12:37:01 ERROR: purgeHostIdx(1,32765) failed [host not
found]
29/Apr/2002 12:37:01 ERROR: purgeHostIdx(1,32766) failed [host not
found]
29/Apr/2002 12:37:01 ERROR: purgeHostIdx(1,32767) failed [host not
Regards
MIKE
On Mon, 2002-04-29 at 12:20, Burton M. Strauss III wrote:
> First off, -s has been removed as -s <hashsize>
>
> It's now a (future) flag to turn off promiscuous mode. That is the code to set it
>is in:
>
> initialize.c: 980 myGlobals.disablePromiscuousMode ==
>1 ? 0 : 1,
> main.c: 452 myGlobals.disablePromiscuousMode = 1;
> globals.h: 105 u_char disablePromiscuousMode;
>
> But that's all.
>
> AFAIK, there is now no limit on hash size growth. The constant is still defined,
>but it's not used anymore:
>
> ntop.h: 1311 #define MAX_HASH_SIZE 32768
>
> The code that resizes the hash is this:
>
> if(!hostFound) {
> int sz;
>
> list->idx = myGlobals.device[actualDeviceId].actualHashSize;
> if(myGlobals.device[actualDeviceId].actualHashSize < 512)
> myGlobals.device[actualDeviceId].actualHashSize = 512;
> else
> myGlobals.device[actualDeviceId].actualHashSize *= 2; /* Double */
> sz = myGlobals.device[actualDeviceId].actualHashSize*sizeof(struct
>hostTraffic*);
> myGlobals.device[actualDeviceId].hash_hostTraffic = (struct
> hostTraffic**)realloc(myGlobals.device[actualDeviceId].hash_hostTraffic, sz);
> memset(&myGlobals.device[actualDeviceId].hash_hostTraffic[list->idx],
> 0, sizeof(struct
>hostTraffic*)*(myGlobals.device[actualDeviceId].actualHashSize-list->idx));
> traceEvent(TRACE_INFO, "Extending hash size [newSize=%d][deviceId=%d]",
> myGlobals.device[actualDeviceId].actualHashSize,
> actualDeviceId);
> } else
>
> The only limit is available memory. Remember that the realloc will - under the
>covers - require enough memory for the new size
> (rounded to a full page) + the original size (it does a malloc, copy, free set
>internally).
>
> Now there is a report that the realloc can fail and cause all kinds of horrible
>problems (and I agree that should be tested for),
> but if you have enough ram, you should be able to grow beyond 32K...
>
> You can TRY the attached patch. It's under development, and will ONLY report the
>error if the realloc fails!!
>
> (All greps are from 2.0.99 ntop-02-04-27.tgz)
>
> -----Burton
>
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
> Michael Baird
> Sent: Monday, April 29, 2002 10:35 AM
> To: [EMAIL PROTECTED]
> Subject: [Ntop] Ntop 29-4-02 snapshot
>
>
> I'm using ntop with the netflow plugin, and it's finally starting to
> look promising, except for a couple of issues. It now compiles
> properly, runs properly, and works properly, however it doesn't clear
> the hash in RAM, my understanding was at 32768 it should clear the hash
> and start over, is this incorrect, or do I need to run it with some
> extra arguments, I tried the -S 1 and -S 2 options, neither work with
> the netflow plugin, -S 0 does. I'm currently using /usr/local/bin/ntop
> -u root -d as my only arguments, I've tried -s <hashsize> as described
> in the FAQ but ntop doesn't pay attention to this either.
>
> Regards
> MIKE
>
>
>
> _______________________________________________
> Ntop mailing list
> [EMAIL PROTECTED]
> http://listgateway.unipi.it/mailman/listinfo/ntop
_______________________________________________
Ntop mailing list
[EMAIL PROTECTED]
http://listgateway.unipi.it/mailman/listinfo/ntop
_______________________________________________
Ntop mailing list
[EMAIL PROTECTED]
http://listgateway.unipi.it/mailman/listinfo/ntop
