On Nov 20, 2014, at 5:47 AM, Clemens Lang wrote: >>> That's on 10.6, where I have indeed seen clang-3.4 consume huge amounts of >>> memory on a single file, AFAIK that compiler wasn't being used. However, if >>> port upgrade outdated uses a single tclsh process for the whole procedure, >>> and >>> it's this process that handles (inefficient) db stuff, that could cause its >>> memory footprint to explode. > > Most of the stuff this tclsh process does is not written in a language that > requires manual memory management. Tcl code doesn't leak memory. > > >> It's certainly possible there is a memory leak in MacPorts base somewhere. > > It's possible that there is a memory leak in the parts of MacPorts written in > C. A lot > of the code is old and hasn't seen maintenance or re-factoring in a while. > I'm pretty > confident the parts I've looked at (registry, darwintrace, tracelib and curl > parts of > pextlib) are leak-free, but that doesn't mean that other parts are.
Sure, I didn't necessarily mean a memory leak in the traditional C sense of a pointer that was allocated but not freed. But it's certainly possible to write code in an interpreted language like Tcl that uses a lot of memory, possibly unnecessarily. It's possible to write code that accumulates a vast quantity of information in a variable, perhaps a global variable, perhaps by appending to that variable and never clearing it. I don't truly understand how base works and fits together, and my feeling is few people do, or someone would have figured out the solution to weird bugs like https://trac.macports.org/ticket/37093 by now. _______________________________________________ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
