Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Verilog-Perl memory leak? #232

Closed
veripoolbot opened this issue Apr 5, 2010 · 4 comments
Closed

Verilog-Perl memory leak? #232

veripoolbot opened this issue Apr 5, 2010 · 4 comments
Assignees

Comments

@veripoolbot
Copy link
Collaborator


Author Name: Jeff Short
Original Redmine Issue: 232 from https://www.veripool.org
Original Date: 2010-04-05
Original Assignee: Wilson Snyder (@wsnyder)


I don't know if this is a Verilog-Perl problem or a problem with perl.

If you do the following:
foreach my $vfile () {
my $nl = new Verilog::Netlist(....)
$nl->read_file(filename=>$vfile);
undef($nl);
}

You will see the memory grow with time, even if all the verilog files are the same size. It seems to me that the memory usage should be the that to cover the largest $nl ever used.

Jeff

@veripoolbot
Copy link
Collaborator Author


Original Redmine Comment
Author Name: Jeff Short
Original Date: 2010-04-05T16:42:27Z


Well the post butchered my code example. Let me know if you want me to provide an actual .pl

Jeff

@veripoolbot
Copy link
Collaborator Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2010-04-05T17:32:52Z


Are you using the most recent release? I thought all leaks were fixed in 2.230 - you'll see the t/48_leak.t test has almost the exact same loop you describe. So, maybe it's data dependent.

@veripoolbot
Copy link
Collaborator Author


Original Redmine Comment
Author Name: Jeff Short
Original Date: 2010-04-05T18:05:59Z


Wilson Snyder wrote:

Are you using the most recent release? I thought all leaks were fixed in 2.230 - you'll see the t/48_leak.t test has almost the exact same loop you describe. So, maybe it's data dependent.

Thanks for pointing me at that. So the difference between your test and mine is:
$nl->delete();

If you have this then there isn't any memory growth. Without it the memory continues to grow.
So I guess chaulk this one up to bad coding on my part.

Jeff

@veripoolbot
Copy link
Collaborator Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2010-04-20T23:23:55Z


Resolved... delete is needed.

Based on your problems I looked at using weak references to solve this problem, but it can cause
other difficulties when people pull off references to modules and such, so I think I'll leave
well enough alone for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants