[petsc-users] PetscMallocAlign

[Barry Smith]

  All mallocs in PETSc go through PetscMallocAlign() (it is just a simple wrapper that makes sure all returned values are double aligned). The problem is not with PetscMallocAlign().  The problem is some objects are not getting destroyed. Likely it is the DA object itself.

   Barry

On Jan 12, 2011, at 1:59 PM, Ataollah Mesgarnejad wrote:

> It's not only the case with Vectors it come up again for example when I use VecView,even though I flush and destroy the viewer  :
> 
> ==3347== 
> ==3347== 18,276 bytes in 1 blocks are possibly lost in loss record 3,420 of 3,439
> ==3347==    at 0x4A04360: memalign (vg_replace_malloc.c:532)
> ==3347==    by 0x8AC2AA: PetscMallocAlign(unsigned long, int, char const*, char const*, char const*, void**) (mal.c:30)
> ==3347==    by 0x8ADBAE: PetscTrMallocDefault(unsigned long, int, char const*, char const*, char const*, void**) (mtr.c:192)
> ==3347==    by 0x9E4350: VecCreate_MPI_Private(_p_Vec*, PetscTruth, int, double const*) (pbvec.c:187)
> ==3347==    by 0x9E4A0A: VecCreate_MPI (pbvec.c:232)
> ==3347==    by 0x9A9F32: VecSetType(_p_Vec*, char const*) (vecreg.c:54)
> ==3347==    by 0x9FEBA0: VecCreateMPI(ompi_communicator_t*, int, int, _p_Vec**) (vmpicr.c:42)
> ==3347==    by 0xBC06F2: DACreateNaturalVector(_p_DA*, _p_Vec**) (dadist.c:99)
> ==3347==    by 0xBC24B8: DAView_VTK(_p_DA*, _p_PetscViewer*) (daview.c:145)
> ==3347==    by 0xBC3336: DAView(_p_DA*, _p_PetscViewer*) (daview.c:244)
> ==3347==    by 0x6D612C: WriteOutput(AppCtx*, int) (PFMAT-Init.cpp:312)
> ==3347==    by 0x6CFE59: main (PFMAT-main.cpp:206)
> ==3347== 
> 
> Ata
> 
> On Jan 12, 2011, at 1:36 PM, Satish Balay wrote:
> 
>> perhaps you are missing a call to VecDestroy() on the vec created by
>> DACreateGlobalVector?
>> 
>> Satish
>> 
>> On Wed, 12 Jan 2011, Ataollah Mesgarnejad wrote:
>> 
>>> Dear All,
>>> 
>>> I have a memory leak problem with my program; it eventually exhausts all the memory on my system and program aborts. I was checking memory usage with Valgrind and there is a persistent error that always traces back PetscMallocAlign. Something like:
>>> 
>>> ==2918== 
>>> ==2918== 18,792 bytes in 2 blocks are possibly lost in loss record 2,256 of 2,257
>>> ==2918==    at 0x4A04360: memalign (vg_replace_malloc.c:532)
>>> ==2918==    by 0x8AC18A: PetscMallocAlign(unsigned long, int, char const*, char const*, char const*, void**) (mal.c:30)
>>> ==2918==    by 0x8ADA8E: PetscTrMallocDefault(unsigned long, int, char const*, char const*, char const*, void**) (mtr.c:192)
>>> ==2918==    by 0x9E4230: VecCreate_MPI_Private(_p_Vec*, PetscTruth, int, double const*) (pbvec.c:187)
>>> ==2918==    by 0x9E48EA: VecCreate_MPI (pbvec.c:232)
>>> ==2918==    by 0x9A9E12: VecSetType(_p_Vec*, char const*) (vecreg.c:54)
>>> ==2918==    by 0x9FEA80: VecCreateMPI(ompi_communicator_t*, int, int, _p_Vec**) (vmpicr.c:42)
>>> ==2918==    by 0xBBFA6C: DACreateGlobalVector(_p_DA*, _p_Vec**) (dadist.c:42)
>>> ==2918==    by 0x6CE34F: main (PFMAT-main.cpp:76)
>>> ==2918== 
>>> 
>>> 
>>> I'm wondering if this is related to a some error in my declarations or a  known issue or an issue at all? 
>>> 
>>> PS: I get the same kind of error both on my Mac os X 10.6 and Fedora 13.
>>> 
>>> Best,
>>> Ata Mesgarnejad
>> 
>