Update of /export/home/ntop/ntop
In directory jabber:/tmp/cvs-serv6049
Modified Files:
ntop.h webInterface.c util.c
Log Message:
1) Add pid information to the mutex lock information. This is reported in
info.html/textinfo.html
2) Move the self-LOCKED message before the attempt so it's generated even if
ntop is running in an environment where the self-LOCK deadlocks the thread.
3) Correct placement of the lockAttempt canary so that it wraps the mutex_lock
call:
strcpy(mutexId->lockAttemptFile, fileName);
mutexId->lockAttemptLine=fileLine;
mutexId->lockAttemptPid=myPid;
rc = pthread_mutex_lock(&(mutexId->mutex));
mutexId->lockAttemptFile[0] = '\0';
mutexId->lockAttemptLine=0;
mutexId->lockAttemptPid=(pid_t) 0;
Paraphrasing from my msg in ntop-dev,
The possibility of the data being stepped on clearly IS there, but that's
why I defined it as a "light-weight" scheme. It's not designed to give 100%
accurate information, but rather to elicit a place to START looking IF a
deadlock occurs.
The idea is to put a canary in the field, set the mutex and then one of two
things happens:
a. You get the mutex and clear the canary.
b. You block and the canary is set until either a) somebody else blocks or
b) the mutex clears and you unblock.
During the time you are blocked, either your canary data is in the fields
for the web server info.html/textinfo.html page to display OR somebody
else's data is, who is ALSO (probably) blocked.
Normal example (time flows down)
Thread #1 #2
setcanary
lock
getslock
clearcanary
setscanary
<processes>
lock
blocks
unlock
getslock
clearcanary
processes
unlock
During the time #2 is blocked, any web server display of
info.html/textinfo.html shows it's blocked and where.
NOTES:
1. A single instantaneous value in "blocked" isn't a deadlock. It's just the
natural blocking of a thread waiting for a resource.
2. Upon refreshing info.html/textinfo.html, if the block is not cleared and/or
the # of locks/unlocks is not changing, then - after 15 or 30s, ntop is probably
deadlocked. Please report the mutex information to the ntop-dev mailing list.
-----Burton (ref 181)
_______________________________________________
Ntop-dev mailing list
[EMAIL PROTECTED]
http://listgateway.unipi.it/mailman/listinfo/ntop-dev
