[LLVMdev] Memory leaks in LLVM

[Chris Lattner]

On Tue, 9 May 2006, Domagoj Babic wrote:

> Hi,
>
> Probably some of the leaks Valgrind reports are spurious, but the numbers
> seem to be significant enough to demand some attention:
>
> ==10132== LEAK SUMMARY:
> ==10132==    definitely lost: 15,624 bytes in 558 blocks.
> ==10132==    indirectly lost: 44,548 bytes in 1,591 blocks.
> ==10132==      possibly lost: 37,576 bytes in 98 blocks.
> ==10132==    still reachable: 1,336,876 bytes in 1,364 blocks.
> ==10132==         suppressed: 0 bytes in 0 blocks.
>
> I know that a patch would be more appreciated, but I still don't feel
> confident enough to fiddle with the LLVM core... Could anyone
> take a look at the report and try fix the leaks?

There is one leak in this report: a leak of some ETForest objects.  This 
is certainly a bug, and if you file a bugzilla bug with the command you 
used and the .bc/.ll file input, I would appreciate it.

One of the confusing things about LLVM is that it has a variety of 
"permanent objects" that it allocates and holds on to.  As valgrind 
indicates, these objects (1364 of them in this case) are not lost, they 
are still reachable.  For clients that want to avoid debug malloc warnings 
or who want to scrape the head of LLVM stuff, there are explicit calls 
(e.g. Constant::clearAllValueMaps) that deallocate this memory.

Most clients don't care, because they are used when LLVM is active, and 
when the program exits they are reclaimed by the OS.

-Chris

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