When checking with valgrind clean up the following:
The arguments for invalid task/function calls.
The simulation callback queues (only needed when the runtime aborts).
Call pthread_exit(NULL) just before exiting to cleanup dynamic loading.
The clang compiler does not like mixing class and struct references. This
patch updates all the struct __vpiHandle, etc. to use class since that is
how they are now defined.
The scope thread rework broek --with-valgrind builds due to the
different handling of the list of threads. Rework valgrind enabled
handling of the thread set within a scope.
This patch adds code to cleanup system functions driving a
continuous assignment. It also modifies the user function
cleanup to not interfere with this. It also adds a count
of the nets and signals that were not cleaned up that is
pnly printed when running valgrind. They are not flagged
y valgrind since they are pool managed objects. There are
a few signals that need to be cleaned up and local nets
are missed so there are a lot of nets.
This patch adds cleanup code that cleans up the memory that is
allocated by the of_EXEC_UFUNC command. This knocks a few more
files off the valgrind list.
This patch adds code to free most of the memory when vvp
finishes. It also adds valgrind hooks to manage the various
memory pools. The functionality is enabled by passing
--with-valgrind to configure. It requires that the
valgrind/memcheck.h header from a recent version of
valgrind be available. It check for the existence of this
file, but not that it is new enough (version 3.1.3 is known
to not work and version 3.4.0 is known to work).
You can still use valgrind when this option is not given,
but you will have memory that is not released and the
memory pools show as a single block.
With this vvp is 100% clean for many of the tests in the
test suite. There are still a few things that need to be
cleaned up, but it should be much easier to find any real
leaks now.
Enabling this causes a negligible increase in run time and
memory. The memory could be a problem for very large
simulations. The increase in run time is only noticeable on
very short simulations where it should not matter.
Stephen Williams
Cary R
Arun Persaud