Memory leaks?

[Shawn]

Hello all, I have created a simple test case that can reproduce the
error (which is an error :) ) and it has been submitted to Cray.  PGI
generally takes these things very seriously, so I would expect them to
attempt fixing it.  This is also not a problem with the gfortran 4.1.2
compiler, although I am not sure that CP2K can be compiled with that.

Thanks,
Shawn


On Jul 14, 9:09 pm, Axel <akoh... at gmail.com> wrote:
> 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... :-(