[LLVMbugs] [Bug 18325] New: leaks in TableGen
bugzilla-daemon at llvm.org
bugzilla-daemon at llvm.org
Wed Dec 25 23:32:51 PST 2013
http://llvm.org/bugs/show_bug.cgi?id=18325
Bug ID: 18325
Summary: leaks in TableGen
Product: new-bugs
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedbugs at nondot.org
Reporter: kcc at google.com
CC: chandlerc at gmail.com, dblaikie at gmail.com,
earthdok at google.com, llvmbugs at cs.uiuc.edu,
samsonov at google.com
Classification: Unclassified
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 http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-December/068997.html
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.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20131226/88bc4148/attachment.html>
More information about the llvm-bugs
mailing list