Bill, I've been running some tests with this configuration (on Linux) and I don't get any complaints about memory leaks. Valgrind also doesn't suspect any leaks in the spot testing that I have done (it does have a problem with some uninitialized data, but that's a different issue to discuss). Is there a specific platform/ configuration/test that triggers the memory checker for you? Also, when I look at the global symbol checker results, it looks like everything fails because nothing can get past the configure stage: http://www.mcs.anl.gov/research/projects/mpich2/todo/globsyms.htm and http://www.mcs.anl.gov/research/projects/mpich2/todo/c-gforker- ch3.log. I agree that the output was generated recently (looks like about 10 mins ago) and that it's building nemesis by default, but I don't see anything about socksm.o anywhere. Was yesterday's output more complete? -Dave On Jul 24, 2008, at 9:04 AM, William Gropp wrote:
(I'm resending this because ANL rejected my original reply)
Yes, I'm looking at those pages (I'm getting to them through http:// wiki.mcs.anl.gov/mpich2/index.php/Developer_Documentation ). The global symbols one has a date of yesterday, and the "ch3" results are clearly for nemesis (the socksm.o file is in the newtcp netmod). The style checker output is recent as well (no dcmfd items).
Special tests must be run manually. The reason that I know about the memory leaks is that I *always* run with
--enable-g=log,mem,dbg --enable-posix=strict
This gives me the earliest warning that there may be problems and great flexibility (because of enable-g=log,dbg) in getting more info about any problems (which is also why the various printfs should use the dbg or log macros - that way, there is a common and available way to enable them when you need them).
Bill