Memory leaks?

[Axel]

hi teo,

thanks a lot for your efforts.
i've forwarded the info to shawn at PSC in the hope
that he can relay it to the PGI people (via cray?).
even with my very limited knowledge of fortran 90/95
this looks like a pretty serious bug and i wonder why
it was not found earlier. let's hope PGI/Cray see it
the same way.

for the record: i updated and recompiled and it works
for me, too (serial and parallel).

cheers,
   axel.

On Jul 14, 8:31 pm, Teodoro Laino <teodor... at gmail.com> wrote:
> I patched the files.. The problem is that there's this bug in the PGI
> compiler:
>
> subroutine pippo()
>    real, allocatable, dimension(:) :: myvar
>
>    ...
>    call pluto()
>
>   contains
>     subroutine pluto()
>     ...
>
>    allocate(myvar(mydim))
>
>    end subroutine pluto
> end subroutine pippo
>
> the variable myvar should be automatically deallocated when exiting
> pippo..
> PGI deallocate it if it's allocated in the same body of the
> subroutine where it is declared (pippo)..
> but if it's allocated  in a contained subroutine (like pluto), PGI
> does NOT deallocate the
> array when exiting from pippo..
>
> If someone of you (Axel??) has contacts with PGI guys just send them
> this bug report..
> introducing the proper deallocation (that are useless according the
> standard but needed to get around the PGI bug) everything works..
> I checked the memory in a geometry optimization and now it's stable
> in a range of +/2MB from the first cycle..
>
> Teo
>
> On 14 Jul 2007, at 21:50, Axel wrote:
>
>
>
> > On Jul 13, 7:33 pm, Teodoro Laino <teodor... at gmail.com> wrote:
>
> > hi teo,
>
> >> Ciao Axel,
>
> >>  From the stack trace you sent I can identify the following modules:
>
> > this is not a stack trace, only parts of a valgrind output.
>
> >> -) cp_units   (not updated since 6 months)
> >> -) input_cp2k_restarts  (relevant possible update 11days ago)
> >> -) cp_output_handling (not updated since 2 months)
> >> -) input_val_types (not updated since 6 months)
>
> > it need not be any of those modules directly, but a
> > utility routine used by them.
>
> >> The only possible problems could than be with input_cp2k_restarts..
> >> But what about the error messages localized in the other modules??
>
> >> Looks more like a general problem of the pgi_trim than something
> >> localized in recent changes..
>
> >> (though you said that the version of the 18-06 was ok!) (did you try
> >> to recompile now with same
> >> compiler/library  that version (18-06-07)?)
>
> >> The strange thing is that I can't reproduce the error you had with
> >> the oldest file H2O-32.inp with
> >> pgi-7.0.4 :((
>
> > please check with how many nodes you are running? that input does
> > only 10 steps and that could fit into the nodes, if you use enough
> > of them.
>
> > i have now made a test with an arch file that is a copy of yours
> > and compiled a serial(!) version of it (so i removed the parallel
> > defines and changed the compiler from ftn to pgf90, using pgi 7.0.4
> > (after a make distclean!). the resulting binary should not include
> > any cray code and runs also on my desktop.
>
> > now if i run tests/QS/H2-md.inp and monitor the memory usage with
> > top, one can see, that the memory consumption goes up in stages of
> > about 15M for each completed scf calculation.
>
> > i sometimes wonder whether there is something like
> > %ifdef annoy_axel
> >    call do_someting_annoying
> > %endif
> > somewhere hidden in the code... ;-)
>
> > ciao,
> >   axel.
>
> >> teo
>
> >> On 13 Jul 2007, at 23:57, Axel wrote:
>
> >>> from looking at the changelog there were some input related
> >>> changes recently, but only the people having implemented
> >>> them can tell, whether there is an alternate way to do
> >>> the same and not trigger this (compiler) bug... :-(