Memory leaks in LLVM

Project Infrastructure LLVM Dev List Archives
1

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?

Thx.
Domagoj

Full report:

==10132== Memcheck, a memory error detector.
==10132== Copyright (C) 2002-2005, and GNU GPL’d, by Julian Seward et al.
==10132== Using LibVEX rev 1575, a library for dynamic binary translation.
==10132== Copyright (C) 2004-2005, and GNU GPL’d, by OpenWorks LLP.
==10132== Using valgrind-3.1.1, a dynamic binary instrumentation framework.
==10132== Copyright (C) 2000-2005, and GNU GPL’d, by Julian Seward et al.
==10132== For more details, rerun with: -v
==10132==

2

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