Well, :) - it can't be GOOD...
it's in this block of code in util.c:
int _accessMutex(PthreadMutex *mutexId, char* where,
char* fileName, int fileLine) {
int rc;
if(!mutexId->isInitialized) {
traceEvent(TRACE_ERROR,
"ERROR: accessMutex() call with a NULL mutex [%s:%d]\n",
fileName, fileLine);
return(-1);
}
called from here in address.c:
static void queueAddress(struct in_addr elem) {
/****************************
- If the queue is full then wait until a slot is freed
- If the queue is getting full then periodically wait
until a slot is freed
*****************************/
if(addressQueueLen >= ADDRESS_QUEUE_LENGTH) {
#ifdef DEBUG
traceEvent(TRACE_INFO, "Dropping address!!! [addr queue=%d/max=%d]\n",
addressQueueLen, maxAddressQueueLen);
#endif
/* The address is kept in numerical form (i.e. no conversion will take
place) */
numKeptNumericAddresses++;
droppedAddresses++;
#ifdef HAVE_SCHED_H
sched_yield(); /* Allow other threads (dequeue) to run */
#endif
} else {
accessMutex(&addressQueueMutex, "queueAddress");
addressQueue[addressQueueHead].s_addr = elem.s_addr;
addressQueueHead = ((addressQueueHead+1) % ADDRESS_QUEUE_LENGTH);
addressQueueLen++;
if(addressQueueLen > maxAddressQueueLen) {
maxAddressQueueLen = addressQueueLen; /* Update stats */
#ifdef DEBUG
traceEvent(TRACE_INFO, "Max queue len: %ld\n", maxAddressQueueLen);
#endif
}
releaseMutex(&addressQueueMutex);
#ifdef DEBUG
traceEvent(TRACE_INFO, "Queued address... [addr queue=%d/max=%d]\n",
addressQueueLen, maxAddressQueueLen);
#endif
I doubt it's fatal on a uniprocessor machine, but on an SMP box, it could be
bad (even on an UP if the interrupts tick just right). Symptoms would be
lost/corrupted DNS name resolutions... the mutex is protecting the queue of
address to resolve. I think you could run a long time without a problem or
get bit immediately. Still, the mutex shouldn't be null - it's initialized
on startup and never touched...
Needed information - the mutex section from the bottom of the configuration
report... also the thread counter (# Active Threads) from the same report.
Note that there is this note in the code in createMutex:
#ifdef PTHREAD_MUTEX_ERRORCHECK_NP
/* *************************************************
There seems to be some problem with mutexes and some
glibc versions. See
http://sdb.suse.de/sdb/de/html/aj_pthread7.0.html
(in German but an english version is probably available on their
international web site). Suggested workaround is either to use
pthread_mutexattr_settype (&mutattr, PTHREAD_MUTEX_ERRORCHECK_NP);
as checked mutexes dont have the error or use a corrected
glibc (Suse offers a patched version for their system).
Andreas Pfaeller <[EMAIL PROTECTED]>
************************************************* */
pthread_mutexattr_settype (&(mutexId->mutex),
PTHREAD_MUTEX_ERRORCHECK_NP);
#endif /* PTHREAD_MUTEX_ERRORCHECK_NP */
You probably need to give us more information about the setup...
Software
NTop version, source and any applied patches
Linux vendor & version
Any major upgrades (kernel, networking, etc.)
gcc version
glibc version
Hardware
Type & # of processors (given in your msg)
# network interfaces and types (vendor, bus, etc.)
I would also suggest restarting NTop and seeing if it goes away...
-----Burton
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf
Of Dennis Schoen
Sent: Monday, January 07, 2002 8:59 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: [Ntop-dev] Re: ntop-2.0.0-1
On Mon, Jan 07, 2002 at 07:44:37AM -0700, [EMAIL PROTECTED] wrote:
> Sorry for the screwy bug report, the system generating the bugs can't send
> email.
>
> In my hourly parsing of logfiles for notification information, I see the
> following:
in which logfile?
> ERROR: accessMutex() call with a NULL mutex [address.c:358]
> ERROR: releaseMutex() call with a NULL mutex [address.c:370]
are you experiencing any problems? I don't think thats problematic
but I'll forward your mail to the ntop-dev mailing list.
> This is on a Dual PPro-200 system testing/unstable.
Ciao
Dennis
_______________________________________________
Ntop-dev mailing list
[EMAIL PROTECTED]
http://listmanager.unipi.it/mailman/listinfo/ntop-dev
_______________________________________________
Ntop-dev mailing list
[EMAIL PROTECTED]
http://listmanager.unipi.it/mailman/listinfo/ntop-dev
