<html>
<head>
<base href="http://llvm.org/bugs/" />
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW --- - leaks in TableGen"
href="http://llvm.org/bugs/show_bug.cgi?id=18325">18325</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>leaks in TableGen
</td>
</tr>
<tr>
<th>Product</th>
<td>new-bugs
</td>
</tr>
<tr>
<th>Version</th>
<td>unspecified
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</td>
</tr>
<tr>
<th>OS</th>
<td>Linux
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>new bugs
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>kcc@google.com
</td>
</tr>
<tr>
<th>CC</th>
<td>chandlerc@gmail.com, dblaikie@gmail.com, earthdok@google.com, llvmbugs@cs.uiuc.edu, samsonov@google.com
</td>
</tr>
<tr>
<th>Classification</th>
<td>Unclassified
</td>
</tr></table>
<p>
<div>
<pre>TableGen has quite a few memory leaks that LeakSanitizer complains about.
Reproduce (on Linux):
cmake -GNinja -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_ASSERTIONS=ON
-DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++
-DLLVM_USE_SANITIZER=Address /home/kcc/llvm
ASAN_OPTIONS=detect_leaks=1 ninja check-clang check-llvm
Some leaks look like this:
Direct leak of 19208 byte(s) in 343 object(s) allocated from:
#0 0x472526 in operator new(unsigned long)
llvm/projects/compiler-rt/lib/asan/asan_new_delete.cc:54
#1 0x8833e7 in llvm::ListInit::get(llvm::ArrayRef<llvm::Init*>,
llvm::RecTy*) llvm/lib/TableGen/Record.cpp:636
#2 0x883016 in llvm::ListRecTy::convertValue(llvm::ListInit*)
llvm/lib/TableGen/Record.cpp:288
#3 0x8c8f62 in setValue llvm/include/llvm/TableGen/Record.h:1360
#4 0x8c8f62 in llvm::TGParser::SetValue(llvm::Record*, llvm::SMLoc,
llvm::Init*, std::vector<unsigned int, std::allocator<unsigned int> > const&,
llvm::Init*) llvm/lib/TableGen/TGParser.cpp:1ยป
#5 0x8caa49 in llvm::TGParser::AddSubClass(llvm::Record*,
llvm::SubClassReference&) llvm/lib/TableGen/TGParser.cpp:168
#6 0x8dfa8c in llvm::TGParser::ParseSimpleValue(llvm::Record*,
llvm::RecTy*, llvm::TGParser::IDParseMode) llvm/lib/TableGen/TGParser.cpp:1226
and are caused by static container object that are destructed at the end of
process w/o deleting the contents:
ListInit *ListInit::get(ArrayRef<Init *> Range, RecTy *EltTy) {
typedef FoldingSet<ListInit> Pool;
static Pool ThePool;
// Just use the FoldingSetNodeID to compute a hash. Use a DenseMap
// for actual storage.
FoldingSetNodeID ID;
ProfileListInit(ID, Range, EltTy);
void *IP = 0;
if (ListInit *I = ThePool.FindNodeOrInsertPos(ID, IP))
return I;
ListInit *I = new ListInit(Range, EltTy);
ThePool.InsertNode(I, IP);
return I;
}
These are easy to fix by replacing
static Pool ThePool;
with
static Pool *ThePool = new Pool;
Other leaks look trickier to fix. Some examples:
Direct leak of 128 byte(s) in 4 object(s) allocated from:
#0 0x4690b6 in operator new(unsigned long)
llvm/projects/compiler-rt/lib/asan/asan_new_delete.cc:54
#1 0x5c5740 in getDefInit llvm/lib/TableGen/Record.cpp:1682
#2 0x5c5740 in llvm::DefInit::get(llvm::Record*)
llvm/lib/TableGen/Record.cpp:1469
#3 0x613aa3 in llvm::TGParser::ParseIDValue(llvm::Record*, std::string
const&, llvm::SMLoc, llvm::TGParser::IDParseMode)
llvm/lib/TableGen/TGParser.cpp:787
#4 0x618f0c in llvm::TGParser::ParseSimpleValue(llvm::Record*,
llvm::RecTy*, llvm::TGParser::IDParseMode) llvm/lib/TableGen/TGParser.cpp:1191
#5 0x60c8d0 in llvm::TGParser::ParseValue(llvm::Record*, llvm::RecTy*,
llvm::TGParser::IDParseMode) llvm/lib/TableGen/TGParser.cpp:1427
#6 0x60f766 in llvm::TGParser::ParseValueList(llvm::Record*, llvm::Record*,
llvm::RecTy*) llvm/lib/TableGen/TGParser.cpp:1616
#7 0x60f206 in llvm::TGParser::ParseSubClassReference(llvm::Record*, bool)
llvm/lib/TableGen/TGParser.cpp:495
Direct leak of 216 byte(s) in 1 object(s) allocated from:
#0 0x4690b6 in operator new(unsigned long)
llvm/projects/compiler-rt/lib/asan/asan_new_delete.cc:54
#1 0x6276fb in llvm::TGParser::ParseMultiClass()
llvm/lib/TableGen/TGParser.cpp:2204
#2 0x623f12 in llvm::TGParser::ParseObject(llvm::MultiClass*)
llvm/lib/TableGen/TGParser.cpp:2569
#3 0x62ea7a in ParseObjectList llvm/lib/TableGen/TGParser.cpp:2577
#4 0x62ea7a in llvm::TGParser::ParseFile()
llvm/lib/TableGen/TGParser.cpp:2585
#5 0x5b1c76 in llvm::TableGenMain(char*, bool (*)(llvm::raw_ostream&,
llvm::RecordKeeper&)) llvm/lib/TableGen/Main.cpp:102
#6 0x5ac8f1 in main llvm/tools/clang/utils/TableGen/TableGen.cpp:249
#7 0x7f69adabb76c in __libc_start_main
/build/buildd/eglibc-2.15/csu/libc-start.c:226
Indirect leak of 384 byte(s) in 2 object(s) allocated from:
#0 0x4690b6 in operator new(unsigned long)
llvm/projects/compiler-rt/lib/asan/asan_new_delete.cc:54
#1 0x6216a2 in llvm::TGParser::ParseDef(llvm::MultiClass*)
llvm/lib/TableGen/TGParser.cpp:1950
#2 0x623ede in llvm::TGParser::ParseObject(llvm::MultiClass*)
llvm/lib/TableGen/TGParser.cpp:2565
#3 0x62806d in llvm::TGParser::ParseMultiClass()
llvm/lib/TableGen/TGParser.cpp:2257
#4 0x623f12 in llvm::TGParser::ParseObject(llvm::MultiClass*)
llvm/lib/TableGen/TGParser.cpp:2569
#5 0x62ea7a in ParseObjectList llvm/lib/TableGen/TGParser.cpp:2577
#6 0x62ea7a in llvm::TGParser::ParseFile()
llvm/lib/TableGen/TGParser.cpp:2585
#7 0x5b1c76 in llvm::TableGenMain(char*, bool (*)(llvm::raw_ostream&,
llvm::RecordKeeper&)) llvm/lib/TableGen/Main.cpp:102
#8 0x5ac8f1 in main llvm/tools/clang/utils/TableGen/TableGen.cpp:249
It's possible to fix all of those leaks, but apparently it's not that
important,
see <a href="http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-December/068997.html">http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-December/068997.html</a>
So, for now I am going to disable lsan for the TableGen binaries using
__lsan_is_turned_off.
See compiler-rt/include/sanitizer/lsan_interface.h for explanation.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>