Barry- Thanks for the correction. I was under the impression that I needed to create and then open.
Yes, I am aware of all the noise that OpenMPI creates with valgrind. Matt's memory allocation stuff in Sieve also creates lots of noise with valgrind but at least they show 0 bytes leaked. Thanks, Brad On 06/01/2011 09:20 AM, Barry Smith wrote: > > Brad, > > The problems valgrind reports are all due to errors in opempi. If you > use --download-mpich that installs a "clean" version of MPICH that has no > memory errors. > > The [0] means process 0. > > The "memory leak reported by -malloc_dump is due to bad example code > > err = PetscViewerBinaryCreate(PETSC_COMM_WORLD,&viewer);CHKERRQ(err); > > err = PetscViewerBinaryOpen(PETSC_COMM_WORLD, "myviewer.dat", > FILE_MODE_WRITE,&viewer); CHKERRQ(err); > > There is no reason for the line PetscViewerBinaryCreate(). It creates an > (unfilled) binary viewer but then PetscViewerBinaryOpen() lies on top of it a > filled one, thus leaking the previous memory. > > There is no reason for the existence of PetscViewerBinaryCreate(), I am > removing it from PETSc-dev. > > > > Barry > > > > On Jun 1, 2011, at 11:05 AM, Brad Aagaard wrote: > >> Hi all: >> >> Valgrind is suggesting that I may have a memory leak associated with >> PetscViewer objects in PyLith. I created a simple example (attached) that >> reproduces the valgrind message. >> >> Is there really a memory leak associated with PetscMallocAlign() or is >> valgrind just confused? >> >> I also ran the example with the -malloc -malloc_debug -malloc_dump flags. >> What do the values in square brackets mean? Does [0] indicate memory was >> freed or not freed? The FAQ on use of -malloc doesn't appear to discuss what >> the output means. >> >> Logs from running the example in valgrind and with the malloc flags are also >> attached. >> >> Thanks, >> Brad >> <log_malloc.txt><log_valgrind.txt><test_viewer.cc> > >
