[LLVMdev] Memory leaks revisited (and many fixed)

Chris Lattner sabre at nondot.org
Fri Nov 19 09:33:46 PST 2004


On Fri, 19 Nov 2004, Morten Ofstad wrote:
> I finally took the time to track down the remaining memory leaks beside
> the LeakDetector objects and TypeMaps/ValueMaps I already knew about. It
> turns out almost all of them came from the command line options module,
> so I cleaned up the patch for LeakDetector and made a new patch for
> CommandLine. The patches are attached to this message.

Looks great, applied:
http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20041115/020970.html
http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20041115/020971.html

> That got rid of all but 4 leaks I'm getting, but of course there are
> more of the same waiting to happen - the pattern of creating singletons
> with new instead of having static objects inside accessor functions is
> very common in LLVM.

Yes it is.  I'm still mostly of the opinion that memory live at exit
shouldn't have to be free'd, but I can appreciate tidiness :)

> The four leaks are caused by the ConstantBool::True
> and ConstantBool::False (1 for each object + 1 for the use list dummy) -
>   unfortunately they are not so easy to wrap with accessor functions
> since they are public member variables of the ConstantBool class... If
> only everyone used the ConstantBool::get() there would be no problem,
> but that's not the case. Any suggestions?

These should just be destroyed along with the rest of the constants, by
Constant::clearAllValueMaps.

-Chris

-- 
http://llvm.org/
http://nondot.org/sabre/





More information about the llvm-dev mailing list