valgrind ... However, with 1.9.3 (the last time I used it), it's just SUCH a pain in the <you know where> to get it setup, and I can't seem to make the ignore rules work, so it's noisy (there's a lot of flaws in the std library and it whines about each of them). But that's the best I've found. It's just hard to let things run long enough to get more than trivial results...
There's a new version, 1.9.6, that might be a lot better... http://developer.kde.org/~sewardj/ -----Burton -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Scott Stone Sent: Monday, June 23, 2003 1:16 PM To: [EMAIL PROTECTED] Subject: RE: [Ntop] web interface looping (PR_C6PVXVX) slightly off topic, Burton, but there was a time that I'd suggest using Electric Fence to debug this - but lately I've had poor luck with it doing anything except causing more problems than it finds.. what replacement malloc() do the ntop devs prefer for debugging such things? I'm looking for a better one... --- "Burton M. Strauss III" <[EMAIL PROTECTED]> wrote: > 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 icrit : > > >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 ===== ------------------- Scott M. Stone <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> Taos - The SysAdmin Company (http://www.taos.com) Cisco Certified Network Associate Sun Solaris Certified Systems Administrator _______________________________________________ Ntop mailing list [EMAIL PROTECTED] http://listgateway.unipi.it/mailman/listinfo/ntop _______________________________________________ Ntop mailing list [EMAIL PROTECTED] http://listgateway.unipi.it/mailman/listinfo/ntop
