My understanding of Fortran bounds checking is that before each array access in Fortran it checks to see if the index is valid for the array you are accessing; that is it is from start to end if you had declared the array as
double precision, dimension (start:end) :: A It should also work if the array is a Fortran allocatable array or if you obtain the array from PETSc with VecGetArrayF90() and all its friends and relations. PETSc should not change the behavior above. Now if there is memory corruption (or some other error) somewhere else (like in PETSc or a more subtle problem in your code) then simply array out of bounds then yes you can get more complicated error messages that would usually include the PETSc stack trace. Instead of using valgrind you can also try running the PETSc program with -malloc_debug, this is sort of a poor person's version of valgrind but can sometimes provide more useful information than valgrind. When debugging always make sure PETSc was NOT ./configure with --with-debugging=0 You can send specific error messages that are cryptic to petsc-ma...@mcs.anl.gov <mailto:petsc-ma...@mcs.anl.gov> and we may be able to help decipher them. Barry > On Nov 21, 2022, at 2:16 PM, Nicholas Arnold-Medabalimi <narno...@umich.edu> > wrote: > > Hi Petsc users > > I'm working on an integration of Petsc into an existing fortran code. Most of > my memory debugging is very primitive and is usually accomplished using the > -check bounds option in the compiler. However with Petsc attached the stack > trace becomes much more opaque compared to the original code. At least as far > as I can tell the error becomes much harder to pin down (just pointing to > libpetsc.so). Any assistance in getting more informative error messages or > checks would be much appreciated. > > Sincerely > Nicholas > > -- > Nicholas Arnold-Medabalimi > > Ph.D. Candidate > Computational Aeroscience Lab > University of Michigan