Displaying 4 results from an estimated 4 matches for "singletonpool".
2004 Nov 11
0
[LLVMdev] LLVM and memory leaks
...t 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 solutio...
2004 Nov 10
2
[LLVMdev] LLVM and memory leaks
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
2004 Nov 11
2
[LLVMdev] LLVM and memory leaks
...nning 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 ac...
2004 Nov 11
0
[LLVMdev] LLVM and memory leaks
>>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. I...