[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