Andrew Piskorski wrote on 8/10/04, 5:27 PM: > On Tue, Aug 10, 2004 at 10:19:32AM +0200, Zoran Vasiljevic wrote: > > > You might want to distinguish between real leaks and pure memory > > consumption. Purify will report real leaks, that is, if you allocate > > Well, yes. But my problem is that my memory consumption is buggy, and > I haven't been able to figure out why. Any suggestions on how I could > track this down? > > I thought perhaps Tcl's "memory trace on" could help give me an idea > of why/when the memory is being allocated, so I built Tcl with > --disable-shared, "MEM_DEBUG_FLAGS = -DTCL_MEM_DEBUG", and > -DUSE_THREAD_ALLOC=0. With that, when I run tclsh8.4 the memory trace > command works just fine, but from AOLserver it errors out with > 'invalid command name "memory"'. So it seems that for some reason the > memory command just plain doesn't work in AOLserver, even if you link > it to a Tcl where the memory command does work. Anybody know why? Is > this normal?
Unfortunately, its not enough to set USE_THREAD_ALLOC to 0, you actually need to remove it as the tclThreadAlloc.c just checks its existence, not its setting (and the config defines it if you enable-threads, which we must do). Not that you must rebuild your AOLserver with this tcl as there are build dependencies on whether tcl has the thread allocator or not (mostly due to the existence/non-existence of Tcl_GetMemoryInfo()) You can do a sanity check to see if your aolserver is using the thread memory allocator by issuing an 'ns_info pools' command. If it returns anything, its still on. If you are still using the pools that could explain why Purify isn't telling you much. I've successfully built and run aolserver with the 'memory' command - however, it was tough to make it useful if you don't know where to focus (too much data). To build, I used --enable-symbols=mem on the tcl config and removed the USE_THREAD_ALLOC from the generated Makefile and tclConfig.csh before doing the tcl make. I built my aolserver against this version of tcl (not immediately sure why this could make a difference but it's worth a try) As Zoran suggested, I usually bring the server up, run it such that it shows the memory growth, issue an ns_shutdown (Ctl-C or SIGTERM will result in the same) and then wade through the sea of potential leak information reported by purify (most of which is benign). If this comes up with nothing, then you could be that you are 'legally' holding onto this data and judiciously cleaning it up on exit. If that's a possibility I'd take a hard look at the data structures which you free up on exit (i.e. have a shutdown callback defined) My other technique is to try and match up the bumps in process size with actions on the server. This can be pretty frustrating in a multi-threaded process. It helps if you have lots of debug log messages and can use 'process of elimination' to remove certain tasks one at a time to see if it makes a difference. I know how frustrating these hunts can be...good luck!! HTH, -Elizabeth -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
