[logo] 
 
Home
News
Activity
About/Contact
Major Tools
  Dinotrace
  Verilator
  Verilog-mode
  Verilog-Perl
Other Tools
  BugVise
  CovVise
  Force-Gate-Sim
  Gspice
  IPC::Locker
  Rsvn
  SVN::S4
  SystemPerl
  Voneline
  WFH
General Info
  Papers

Issue #550

Memory corruption when parsing modules with triangle dependancy

Added by Ted Campbell 10 months ago. Updated 10 months ago.

Status:ClosedStart date:08/15/2012
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:Parser
Target version:-

Description

There is memory corruption when modules are instantiated with a triangle pattern. The error only occurs if C is instantiated before B. Disabling the destructor of VSymGraph resolves the issue, but of course introduces a memory leak. It isn't obvious to me where the correct fix would go.

Fails against 3.840 and master branch. Passes on 3.833.

A
|\
| B
|/
C
// A.v
module A;
    C c();
    B b();
endmodule

// B.v
module B;
    C c();
endmodule

// C.v
module C;
    initial
        $display( "Hello World" );
endmodule
> valgrind verilator_bin --lint-only A.v

==2854== Invalid read of size 8
==2854==    at 0x40667D: VSymEnt::nodep() const (V3SymTable.h:96)
==2854==    by 0x44EA27: V3ParseImp::lexToken() (verilog.l:1130)
==2854==    by 0x44EB5B: V3ParseImp::lexToBison() (verilog.l:1150)
==2854==    by 0x40EBF3: yyparse() (verilog.c:7757)
==2854==    by 0x429D18: V3ParseImp::bisonParse() (verilog.y:3283)
==2854==    by 0x404BE6: V3ParseImp::lexFile(std::string const&) (V3ParseImp.cpp:156)
==2854==    by 0x40539E: V3ParseImp::parseFile(FileLine*, std::string const&, bool, std::string const&) (V3ParseImp.cpp:143)
==2854==    by 0x405417: V3Parse::parseFile(FileLine*, std::string const&, bool, std::string const&) (V3ParseImp.cpp:170)
==2854==    by 0x5905F8: LinkCellsVisitor::visit(AstCell*, AstNUser*) (V3LinkCells.cpp:206)
==2854==    by 0x4974AB: AstCell::accept(AstNVisitor&, AstNUser*) (V3AstNodes.h:1283)
==2854==    by 0x48ECB4: AstNode::iterateAndNext(AstNVisitor&, AstNUser*) (V3Ast.cpp:768)
==2854==    by 0x48EE0E: AstNode::iterateChildren(AstNVisitor&, AstNUser*) (V3Ast.cpp:748)
==2854==  Address 0x5982300 is 48 bytes inside a block of size 88 free'd
==2854==    at 0x4C26DCF: operator delete(void*) (vg_replace_malloc.c:387)
==2854==    by 0x40A43C: VSymGraph::~VSymGraph() (V3SymTable.h:221)
==2854==    by 0x40A4D1: V3ParseSym::~V3ParseSym() (V3ParseImp.h:200)
==2854==    by 0x405A12: V3ParseImp::~V3ParseImp() (V3ParseImp.cpp:67)
==2854==    by 0x405B12: V3Parse::~V3Parse() (V3ParseImp.cpp:166)
==2854==    by 0x5907B9: LinkCellsVisitor::visit(AstCell*, AstNUser*) (V3LinkCells.cpp:214)
==2854==    by 0x4974AB: AstCell::accept(AstNVisitor&, AstNUser*) (V3AstNodes.h:1283)
==2854==    by 0x48ECB4: AstNode::iterateAndNext(AstNVisitor&, AstNUser*) (V3Ast.cpp:768)
==2854==    by 0x48EE0E: AstNode::iterateChildren(AstNVisitor&, AstNUser*) (V3Ast.cpp:748)
==2854==    by 0x58FA5E: LinkCellsVisitor::visit(AstNodeModule*, AstNUser*) (V3LinkCells.cpp:182)
==2854==    by 0x47D189: AstNVisitor::visit(AstModule*, AstNUser*) (V3Ast__gen_visitor.h:119)
==2854==    by 0x42BDD9: AstModule::accept(AstNVisitor&, AstNUser*) (V3AstNodes.h:1222)

A.v (42 Bytes) Ted Campbell, 08/15/2012 07:08 pm

B.v (31 Bytes) Ted Campbell, 08/15/2012 07:08 pm

C.v (67 Bytes) Ted Campbell, 08/15/2012 07:08 pm

History

#1 Updated by Wilson Snyder 10 months ago

Unsurprisingly on my system valgrind is content. I'll walk through the changes and see if something around there jumps out at me.

#2 Updated by Wilson Snyder 10 months ago

  • Status changed from New to Resolved

I'm not quite sure why this didn't fail in prior versions since the fundamental lifetime of the structure in question was wrong. The fix was to have the parse symbol table persist across all parse runs. This is probably more correct than before, but may result in some fallout if people relied on data types not being persistent across separately parsed cells.

Anyhow believe fixed in git towards 3.841.

#3 Updated by Ted Campbell 10 months ago

Thanks. My design now passes with latest git.

#4 Updated by Wilson Snyder 10 months ago

  • Status changed from Resolved to Closed

In 3.841.

Also available in: Atom PDF