[LLVMbugs] [Bug 6662] New: TableGen leaks lots of memory

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Sat Mar 20 13:55:10 PDT 2010


http://llvm.org/bugs/show_bug.cgi?id=6662

           Summary: TableGen leaks lots of memory
           Product: tools
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: TableGen
        AssignedTo: clattner at apple.com
        ReportedBy: jyasskin at google.com
                CC: llvmbugs at cs.uiuc.edu


For example, we have:

RecordVal::RecordVal(const std::string &N, RecTy *T, unsigned P)
  : Name(N), Ty(T), Prefix(P) {
  Value = Ty->convertValue(new UnsetInit());
...

but

Init *BitsRecTy::convertValue(UnsetInit *UI) {
  BitsInit *Ret = new BitsInit(Size);

  for (unsigned i = 0; i != Size; ++i)
    Ret->setBit(i, new UnsetInit());
  return Ret;
}

which simply drops its argument.


We can either fix tblgen, which could be a lot of work, or we can XFAIL its
tests under valgrind.

Here's a sample valgrind --leak-check=full run:


******************** TEST 'LLVM :: TableGen/eq.td' FAILED ********************
Script:
--
tblgen /Users/jyasskin/src/llvm/trunk/src/test/TableGen/eq.td | FileCheck
/Users/jyasskin/src/llvm/trunk/src/test/TableGen/eq.td
--
Exit Code: 1
Command Output (stdout):
--
Command has output on stderr!

--
Command Output (stderr):
--
==21657== Memcheck, a memory error detector
==21657== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==21657== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==21657== Command: tblgen
/Users/jyasskin/src/llvm/trunk/src/test/TableGen/eq.td
==21657== 
==21657== Warning: ignored attempt to set SIGUSR2 handler in sigaction();
==21657==          the SIGUSR2 signal is used internally by Valgrind
==21657== 
==21657== HEAP SUMMARY:
==21657==     in use at exit: 1,291 bytes in 44 blocks
==21657==   total heap usage: 220 allocs, 176 frees, 24,141 bytes allocated
==21657== 
==21657== 4 bytes in 1 blocks are definitely lost in loss record 7 of 31
==21657==    at 0x4CCAD3: operator new(unsigned long) (vg_replace_malloc.c:220)
==21657==    by 0xFF1AA: llvm::TGParser::ParseType() (TGParser.cpp:581)
==21657==    by 0x102BD2: llvm::TGParser::ParseDeclaration(llvm::Record*, bool)
(TGParser.cpp:1446)
==21657==    by 0x1093B2: llvm::TGParser::ParseBodyItem(llvm::Record*)
(TGParser.cpp:1528)
==21657==    by 0x109A33: llvm::TGParser::ParseBody(llvm::Record*)
(TGParser.cpp:1590)
==21657==    by 0x109D15: llvm::TGParser::ParseObjectBody(llvm::Record*)
(TGParser.cpp:1635)
==21657==    by 0x10A047: llvm::TGParser::ParseClass() (TGParser.cpp:1715)
==21657==    by 0x10B752: llvm::TGParser::ParseObject() (TGParser.cpp:2025)
==21657==    by 0x10B79C: llvm::TGParser::ParseObjectList() (TGParser.cpp:2034)
==21657==    by 0x10B7D9: llvm::TGParser::ParseFile() (TGParser.cpp:2042)
==21657==    by 0x11274E: ParseFile(std::string const&,
std::vector<std::string, std::allocator<std::string> > const&,
llvm::SourceMgr&) (TableGen.cpp:174)
==21657==    by 0x112821: main (TableGen.cpp:184)
==21657== 
==21657== 4 bytes in 1 blocks are definitely lost in loss record 8 of 31
==21657==    at 0x4CCAD3: operator new(unsigned long) (vg_replace_malloc.c:220)
==21657==    by 0xD6401: llvm::RecordVal::RecordVal(std::string const&,
llvm::RecTy*, unsigned int) (Record.cpp:1266)
==21657==    by 0x102F26: llvm::TGParser::ParseDeclaration(llvm::Record*, bool)
(TGParser.cpp:1469)
==21657==    by 0x1093B2: llvm::TGParser::ParseBodyItem(llvm::Record*)
(TGParser.cpp:1528)
==21657==    by 0x109A33: llvm::TGParser::ParseBody(llvm::Record*)
(TGParser.cpp:1590)
==21657==    by 0x109D15: llvm::TGParser::ParseObjectBody(llvm::Record*)
(TGParser.cpp:1635)
==21657==    by 0x10A047: llvm::TGParser::ParseClass() (TGParser.cpp:1715)
==21657==    by 0x10B752: llvm::TGParser::ParseObject() (TGParser.cpp:2025)
==21657==    by 0x10B79C: llvm::TGParser::ParseObjectList() (TGParser.cpp:2034)
==21657==    by 0x10B7D9: llvm::TGParser::ParseFile() (TGParser.cpp:2042)
==21657==    by 0x11274E: ParseFile(std::string const&,
std::vector<std::string, std::allocator<std::string> > const&,
llvm::SourceMgr&) (TableGen.cpp:174)
==21657==    by 0x112821: main (TableGen.cpp:184)
==21657== 
==21657== 8 bytes in 2 blocks are definitely lost in loss record 11 of 31
==21657==    at 0x4CCAD3: operator new(unsigned long) (vg_replace_malloc.c:220)
==21657==    by 0xD6401: llvm::RecordVal::RecordVal(std::string const&,
llvm::RecTy*, unsigned int) (Record.cpp:1266)
==21657==    by 0x102F26: llvm::TGParser::ParseDeclaration(llvm::Record*, bool)
(TGParser.cpp:1469)
==21657==    by 0x10325E: llvm::TGParser::ParseTemplateArgList(llvm::Record*)
(TGParser.cpp:1499)
==21657==    by 0x10A028: llvm::TGParser::ParseClass() (TGParser.cpp:1711)
==21657==    by 0x10B752: llvm::TGParser::ParseObject() (TGParser.cpp:2025)
==21657==    by 0x10B79C: llvm::TGParser::ParseObjectList() (TGParser.cpp:2034)
==21657==    by 0x10B7D9: llvm::TGParser::ParseFile() (TGParser.cpp:2042)
==21657==    by 0x11274E: ParseFile(std::string const&,
std::vector<std::string, std::allocator<std::string> > const&,
llvm::SourceMgr&) (TableGen.cpp:174)
==21657==    by 0x112821: main (TableGen.cpp:184)
==21657== 
==21657== 35 (12 direct, 23 indirect) bytes in 1 blocks are definitely lost in
loss record 23 of 31
==21657==    at 0x4CCAD3: operator new(unsigned long) (vg_replace_malloc.c:220)
==21657==    by 0xFE976: llvm::TGParser::ParseIDValue(llvm::Record*,
std::string const&, llvm::SMLoc) (TGParser.cpp:651)
==21657==    by 0x107530: llvm::TGParser::ParseSimpleValue(llvm::Record*,
llvm::RecTy*) (TGParser.cpp:1046)
==21657==    by 0x102335: llvm::TGParser::ParseValue(llvm::Record*,
llvm::RecTy*) (TGParser.cpp:1288)
==21657==    by 0x103034: llvm::TGParser::ParseDeclaration(llvm::Record*, bool)
(TGParser.cpp:1476)
==21657==    by 0x1093B2: llvm::TGParser::ParseBodyItem(llvm::Record*)
(TGParser.cpp:1528)
==21657==    by 0x109A33: llvm::TGParser::ParseBody(llvm::Record*)
(TGParser.cpp:1590)
==21657==    by 0x109D15: llvm::TGParser::ParseObjectBody(llvm::Record*)
(TGParser.cpp:1635)
==21657==    by 0x10A047: llvm::TGParser::ParseClass() (TGParser.cpp:1715)
==21657==    by 0x10B752: llvm::TGParser::ParseObject() (TGParser.cpp:2025)
==21657==    by 0x10B79C: llvm::TGParser::ParseObjectList() (TGParser.cpp:2034)
==21657==    by 0x10B7D9: llvm::TGParser::ParseFile() (TGParser.cpp:2042)
==21657==    by 0x11274E: ParseFile(std::string const&,
std::vector<std::string, std::allocator<std::string> > const&,
llvm::SourceMgr&) (TableGen.cpp:174)
==21657==    by 0x112821: main (TableGen.cpp:184)
==21657== 
==21657== 44 (24 direct, 20 indirect) bytes in 1 blocks are definitely lost in
loss record 25 of 31
==21657==    at 0x4CCAD3: operator new(unsigned long) (vg_replace_malloc.c:220)
==21657==    by 0xD5E9C: llvm::TernOpInit::resolveReferences(llvm::Record&,
llvm::RecordVal const*) (Record.cpp:998)
==21657==    by 0xDB9B6: llvm::Record::resolveReferencesTo(llvm::RecordVal
const*) (Record.cpp:1302)
==21657==    by 0x100A24: llvm::TGParser::AddSubClass(llvm::Record*,
llvm::SubClassReference&) (TGParser.cpp:168)
==21657==    by 0x109AF5: llvm::TGParser::ParseObjectBody(llvm::Record*)
(TGParser.cpp:1619)
==21657==    by 0x10A3ED: llvm::TGParser::ParseDef(llvm::MultiClass*)
(TGParser.cpp:1672)
==21657==    by 0x10B727: llvm::TGParser::ParseObject() (TGParser.cpp:2023)
==21657==    by 0x10B79C: llvm::TGParser::ParseObjectList() (TGParser.cpp:2034)
==21657==    by 0x10B7D9: llvm::TGParser::ParseFile() (TGParser.cpp:2042)
==21657==    by 0x11274E: ParseFile(std::string const&,
std::vector<std::string, std::allocator<std::string> > const&,
llvm::SourceMgr&) (TableGen.cpp:174)
==21657==    by 0x112821: main (TableGen.cpp:184)
==21657== 
==21657== 44 (24 direct, 20 indirect) bytes in 1 blocks are definitely lost in
loss record 26 of 31
==21657==    at 0x4CCAD3: operator new(unsigned long) (vg_replace_malloc.c:220)
==21657==    by 0xD5F3E: llvm::TernOpInit::resolveReferences(llvm::Record&,
llvm::RecordVal const*) (Record.cpp:1002)
==21657==    by 0xDB9B6: llvm::Record::resolveReferencesTo(llvm::RecordVal
const*) (Record.cpp:1302)
==21657==    by 0x100A24: llvm::TGParser::AddSubClass(llvm::Record*,
llvm::SubClassReference&) (TGParser.cpp:168)
==21657==    by 0x109AF5: llvm::TGParser::ParseObjectBody(llvm::Record*)
(TGParser.cpp:1619)
==21657==    by 0x10A3ED: llvm::TGParser::ParseDef(llvm::MultiClass*)
(TGParser.cpp:1672)
==21657==    by 0x10B727: llvm::TGParser::ParseObject() (TGParser.cpp:2023)
==21657==    by 0x10B79C: llvm::TGParser::ParseObjectList() (TGParser.cpp:2034)
==21657==    by 0x10B7D9: llvm::TGParser::ParseFile() (TGParser.cpp:2042)
==21657==    by 0x11274E: ParseFile(std::string const&,
std::vector<std::string, std::allocator<std::string> > const&,
llvm::SourceMgr&) (TableGen.cpp:174)
==21657==    by 0x112821: main (TableGen.cpp:184)
==21657== 
==21657== 116 (40 direct, 76 indirect) bytes in 2 blocks are definitely lost in
loss record 28 of 31
==21657==    at 0x4CCAD3: operator new(unsigned long) (vg_replace_malloc.c:220)
==21657==    by 0xD5D18: llvm::BinOpInit::resolveReferences(llvm::Record&,
llvm::RecordVal const*) (Record.cpp:759)
==21657==    by 0xD5DC0: llvm::TernOpInit::resolveReferences(llvm::Record&,
llvm::RecordVal const*) (Record.cpp:989)
==21657==    by 0xDB9B6: llvm::Record::resolveReferencesTo(llvm::RecordVal
const*) (Record.cpp:1302)
==21657==    by 0x100A24: llvm::TGParser::AddSubClass(llvm::Record*,
llvm::SubClassReference&) (TGParser.cpp:168)
==21657==    by 0x109AF5: llvm::TGParser::ParseObjectBody(llvm::Record*)
(TGParser.cpp:1619)
==21657==    by 0x10A3ED: llvm::TGParser::ParseDef(llvm::MultiClass*)
(TGParser.cpp:1672)
==21657==    by 0x10B727: llvm::TGParser::ParseObject() (TGParser.cpp:2023)
==21657==    by 0x10B79C: llvm::TGParser::ParseObjectList() (TGParser.cpp:2034)
==21657==    by 0x10B7D9: llvm::TGParser::ParseFile() (TGParser.cpp:2042)
==21657==    by 0x11274E: ParseFile(std::string const&,
std::vector<std::string, std::allocator<std::string> > const&,
llvm::SourceMgr&) (TableGen.cpp:174)
==21657==    by 0x112821: main (TableGen.cpp:184)
==21657== 
==21657== 164 (24 direct, 140 indirect) bytes in 1 blocks are definitely lost
in loss record 29 of 31
==21657==    at 0x4CCAD3: operator new(unsigned long) (vg_replace_malloc.c:220)
==21657==    by 0x10705B: llvm::TGParser::ParseOperation(llvm::Record*)
(TGParser.cpp:966)
==21657==    by 0x109130: llvm::TGParser::ParseSimpleValue(llvm::Record*,
llvm::RecTy*) (TGParser.cpp:1272)
==21657==    by 0x102335: llvm::TGParser::ParseValue(llvm::Record*,
llvm::RecTy*) (TGParser.cpp:1288)
==21657==    by 0x10355D: llvm::TGParser::ParseValueList(llvm::Record*,
llvm::Record*, llvm::RecTy*) (TGParser.cpp:1405)
==21657==    by 0x103C14: llvm::TGParser::ParseSubClassReference(llvm::Record*,
bool) (TGParser.cpp:397)
==21657==    by 0x109AAA: llvm::TGParser::ParseObjectBody(llvm::Record*)
(TGParser.cpp:1613)
==21657==    by 0x10A047: llvm::TGParser::ParseClass() (TGParser.cpp:1715)
==21657==    by 0x10B752: llvm::TGParser::ParseObject() (TGParser.cpp:2025)
==21657==    by 0x10B79C: llvm::TGParser::ParseObjectList() (TGParser.cpp:2034)
==21657==    by 0x10B7D9: llvm::TGParser::ParseFile() (TGParser.cpp:2042)
==21657==    by 0x11274E: ParseFile(std::string const&,
std::vector<std::string, std::allocator<std::string> > const&,
llvm::SourceMgr&) (TableGen.cpp:174)
==21657==    by 0x112821: main (TableGen.cpp:184)
==21657== 
==21657== LEAK SUMMARY:
==21657==    definitely lost: 140 bytes in 10 blocks
==21657==    indirectly lost: 279 bytes in 24 blocks
==21657==      possibly lost: 0 bytes in 0 blocks
==21657==    still reachable: 532 bytes in 2 blocks
==21657==         suppressed: 340 bytes in 8 blocks
==21657== Reachable blocks (those to which a pointer was found) are not shown.
==21657== To see them, rerun with: --leak-check=full --show-reachable=yes
==21657== 
==21657== For counts of detected and suppressed errors, rerun with: -v
==21657== ERROR SUMMARY: 8 errors from 8 contexts (suppressed: 0 from 0)

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.



More information about the llvm-bugs mailing list