Hi, I fixed my initial problem with the order of static destructors, so the program no longer crashes on shutdown. However I'm getting a lot of warnings about memory leaks -- it seems the LLVM type factories are creating objects in their 'get' method which are never deleted. This is unacceptable because these warnings make it very hard to track if any other memory is leaking from the application. I tried deleting these types but ran into problems with the ContainedTys referencing types which have already been deleted causing the application to crash when calling the destructor. It seems that to delete the types properly on program exit the reference counting has to be enabled also for types which are not abstract -- is this possible? m.
I guess the issue of singleton objects leaking is not something that he LLVM team is very concerned about, since there has been no replies to my first mail... But for me it is a big problem. I can't use LLVM in our project if it triggers our leak detection system, since it will hide other problems. Since actually deleting these objects is proving difficult (types can have circular references, so you have to deal with things getting deleted while there are still references to them), I propose to introduce a new class SingletonPool to lib/Support which keeps all the singleton instances and can be free'd without actually calling the destructors, thus stopping our memory leak detection system from complaining. All it would require is using new(SingletonPool) when creating singleton objects. Is this an acceptable solution that you would accept patches for? m.
On Thu, 11 Nov 2004, Morten Ofstad wrote:> I guess the issue of singleton objects leaking is not something that he > LLVM team is very concerned about, since there has been no replies to my > first mail... But for me it is a big problem. I can't use LLVM in our > project if it triggers our leak detection system, since it will hide > other problems.Hi Morten, I appologize for not getting back to you sooner, I've been running behind on a project for a deadline thursday night.> Since actually deleting these objects is proving difficult (types can > have circular references, so you have to deal with things getting > deleted while there are still references to them), I propose to > introduce a new class SingletonPool to lib/Support which keeps all the > singleton instances and can be free'd without actually calling the > destructors, thus stopping our memory leak detection system from > complaining. All it would require is using new(SingletonPool) when > creating singleton objects. Is this an acceptable solution that you > would accept patches for?Can you sketch out a little bit more concretely what you're thinking? In particular, we really don't want to add any per-type or per-constant overhead (note that constants have the same issue you're running into with types), at least for a release build. Are you thinking of a map off to the side that just invokes all of the destructors of all types? -Chris -- http://llvm.org/ http://nondot.org/sabre/