Since the fork()ed child has it's own, entire, static copy of memory, the mutex is actually useless. It's protecting against something, but 1) the update in the parent is of the live version, not the child's copy and 2) the memory backing the mutexes aren't shared, so a lock in one isn't seen by the other.
However, since the fork()ed child's memory is a static copy of the live version at the instant of the fork(), these are just protecting the child against itself and do nothing. The version of the patch I'm going to commit will just use the atfork() handler to reinit the mutex in the child. Since it does NOTHING, it's ok to let it play with itself. No harm, no foul. Realistically, the fork()ed child only mutex logic should be removed and the cases where the code is shared between the parent and child should be examined in more detail - hence the message to trap the invalid cases, which is what I'll be putting into 2.2.x at first, so we get the reports of where mutexes are being set in the child, with the mistaken impression that it does anything. As to what bad code in 2.2 is corrupting memory and cause the root allocation problem, I've still got no clue. It's probably a double free of malloc()ed memory, but I don't see anything obvious. -----Burton -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Mike Tremaine Sent: Sunday, June 22, 2003 10:41 AM To: [EMAIL PROTECTED] Subject: Re: [Ntop] web interface looping (PR_C6PVXVX) Just to report to the list. I backed Redhat 8.0 intall to Ntop 2_2_patches with BMS0282 and 0283 and I hacked config.h to undef /* Define to 1 if you have the <zlib.h> header file. */ /* #define HAVE_ZLIB_H 1 */ and /* ZLIB is available */ /* #define MAKE_WITH_ZLIB 1 */ And rebuilt it. Amazingly the Web looping is gone. :) Thanks Burton. I do notice this in the logs now when I click on STATS->TRAFFIC Jun 22 15:31:27 ntop[24981]: **ERROR** ERROR: accessMutex() call with an INVALID mutex [report.c:2932] Jun 22 15:31:28 ntop[24981]: **ERROR** ERROR: releaseMutex() call with an INVALID mutex [report.c:2977] Jun 22 15:31:29 ntop[24991]: **ERROR** ERROR: accessMutex() call with an INVALID mutex [graph.c:1636] Jun 22 15:31:29 ntop[24991]: **ERROR** ERROR: releaseMutex() call with an INVALID mutex [graph.c:1655] On Friday 20 June 2003 06:49 am, Dominique Lalot wrote: > If we can't rely safely on gzip, How can we disable compression?. > That could solve most of my problems!. > > Concerning 2.2, it's not safe against GD failure, so I avoid it. :-( > > Thanks > > Dominique > > A 12:10 19/06/2003 -0500, vous avez �crit : > >I never said ANYTHING about 2.2.2 - the patch is against the > >ntop_2_2_patches branch. > > > >This sounds like the same gzflush() et al problem I reported a long time > >ago, TPG2XT6 - gzflush() failure, of which CVVJCLB - Middle frame, Solaris > > 8 is a dup. > > > >I've talked to the gzip folks, all they can suggest is something is > > screwing up memory allocations, causing gzflush() or other stream based > > failures. A loop in free() would, as I suggested previously, also be > > from the same basic problem. > > > >The only solution I've found, so far, is to disable the compression of > >ntop's pages. IMHO this isn't a big deal, as most pages are small. I > > will say that the whole bit of logic, using a global variable in http.c > > for the gzip fd seems problematic. > > > >-----Burton > > > > > >-----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Mike > > >Tremaine > >Sent: Thursday, June 19, 2003 11:41 AM > >To: [EMAIL PROTECTED] > >Subject: Re: [Ntop] web interface looping (PR_C6PVXVX) > > > > > >Just FYI patch 283 is not 100% compatible with 2.2.2 several "hunks" fail > >and it prevents Ntop from compiling (besure to use patch -p0 -b < > > <thepatch> when applying to make backups). > > > >Also I applied patch 283 to 2.2 and it did not stop the looping error > > under linux. > > > >I have more debugging sessions to post from this problem but I need more > >time. > > > >Also check your /tmp directory and see if you have a whole bunch of > >gzip.<PID>.ntop files. I think that these get left behind by the looping > > but I'm not sure yet. > > > >Mike Tremaine > > > >_______________________________________________ > >Ntop mailing list > >[EMAIL PROTECTED] > >http://listgateway.unipi.it/mailman/listinfo/ntop -- Mike Tremaine [EMAIL PROTECTED] _______________________________________________ Ntop mailing list [EMAIL PROTECTED] http://listgateway.unipi.it/mailman/listinfo/ntop _______________________________________________ Ntop mailing list [EMAIL PROTECTED] http://listgateway.unipi.it/mailman/listinfo/ntop
