This is a known issue without a perfect solution. The problem is that by default PETSc fortran types, like type(tKSP) are not initialized but we want to check if they are a special null character, for example PETSC_NULL_KSP. So we could initialize them but then they cannot be used in common blocks (since default initialized Fortran90 types cannot be used in common blocks; some strange feature of Fortran 90)
In next you can configure with the option -with-fortran-type-initialize=1 and the valgrind errors will go away, but then there cannot be Fortran datatypes into common blocks. Barry It may be we should make -with-fortran-type-initialize=1 the default but this will break some PETSc Fortran examples that use common blocks. We should rewrite those examples not to use common blocks but who volunteers? > On Jan 18, 2018, at 4:11 PM, Randall Mackie <[email protected]> wrote: > > The very simple attached program throws lots of valgrind errors. > I am using pets 3.8.3, compiled with the following options: > > > ./configure \ > --with-debugging=1 \ > --with-fortran=1 \ > --download-mpich=../mpich-3.3a2.tar.gz \ > > > The makefile, run file, and valgrind output are also attached. > > > Randy M. > > > > > <cmd_test><makefile><test.F90><valgrind.txt>
