Memory leaks?

[Axel]

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... :-(