OSVVM™ 2014.07a: Protected Types, Initialized Pointers, and Memory Leaks

I have just posted release 2014.07a. There are no new features in this release. It fixes memory leaks.

The first (and biggest) issue is in the deallocate procedure in CoveragePkg for CovPType. The Name of each coverage bin is never deallocated when deallocate is called. If you called deallocate during your testing process, the space allocated for the bin names was never given back. Hence, if you are currently calling deallocate in CoveragePkg, then you need this update. This issue is only in release 2014.07.

The next one is created by usage. If you declare a coverage model within a temporary object, such as a subprogram, before that subprogram exits, you must call deallocate on the coverage object. If you fail to do this, then there will be a memory leak. If you are using coverage models this way, you need this update. This issue is true about all releases of CoveragePkg since the coverage model, by necessity, is dynamically allocated.

The final ones I found are more subtle. They result from a collision of creating a coverage model within a temporary object and initializing pointers within a protected type. I took to initializing pointers so I could avoid having to do NULL checks. For example, in NamePkg, I did:
variable NamePtr : line := new string'("") ;
And then when I did a “Get” on the string value, I can skip the NULL check on NamePtr:
impure function Get return string is
begin
return NamePtr.all ;
end function Get ;
Cool, but that means that the protected type needs a deallocate/destructor that only runs if you are never going to call a method on the protected type object again – such as a the end of a subprogram that declares an object of the protected type. Without something that happens automatically as the object is being destroyed, that is a hard use mode to remember. I instead added a check to return “” on NULL to Get. This issue is in revisions 2014.07 and 2014.01.

A testbench that declares a coverage object in an architecture or process, creates the coverage model, collects coverage while the test is running, and completes the simulation at some point (due to coverage closure or other condition) should not experience any issues with memory leaks.

So yes, put automatic garbage collection on my wish list for the next revision of the language.