Valgring Use for GEOtop

== Instructions ==

Now we downlaoded valgrid 3.5 on MACOS X from here

http://valgrind.org/downloads/current.html#current

then I launched the ./configure script, make and make install.

$ ./configure ${options}

and then

$ make

and

$ make install

=== Further Details ==

See detailed instructions:

http://valgrind.org/docs/manual/QuickStart.html

Useful tips:

http://valgrind.org/docs/manual/dist.install.html

http://valgrind.org/docs/manual/valgrind_manual.pdf

http://valgrind.org/docs/manual/manual-intro.html#manual-intro.overview

http://valgrind.org/

== How To Solve the Bugs in GEOtop ==

Then type valgrind from the command line, if the command is recognized launch a simulation of GEOtop from the command line in the following way:

$ valgrind ${options} ./geotop ${simulation_wapth}

At the end of simulation the output can show you the memory leakeages, the uninitialized variables and the errors. You will sse the routines where the lost memory was allocated and the routines which contain the errors. Use the following options (see manual for further details):

  valgrind --leak-check=full ./geotop ${simulation_wapth}

to see memory lost) - I suggest this at the first launch!!!

  valgrind --track-origins=yes ./geotop ${simulation_wapth}

to see uninitialized variables.

Useful Suggestions

You can use both otions above and others but, for a better readability use one option per each launched simulation. This is my suggestion! As Thomas Egger reported in the mail below, try different kinds of simulations with Valgrind.

....

Here it is reported the email from Thomas Egger in the mailing list of developers: Dear all,

in order to make sure that we're not debugging the same code twice I think that we should submit corrected bugs to the SVN as soon as the new version that Matteo announced last week is uploaded. Thank you Emanuele for your efforts!

Here are instructions for the two debugging techniques presented during our meeting:

1) Floating point error detection: activating flags in the floating point environment, so that the program raises exceptions when encountering divisions by zero, calculations involving NaN, etc.

include the follwing header in geotop.c: #include <fenv.h>

as a first instruction in main add: feenableexcept(FE_DIVBYZERO | FE_INVALID | FE_OVERFLOW ); //for halting the process on arithmetic exceptions

There are some more options: http://www.digitalmars.com/rtl/fenv.html Once the program terminates on SIG_FPE, the core should be inspected in a debugger of choice (e.g. gdb):

# gdb ./geotop

GDB is free software and you are welcome to distribute copies of it

under certain conditions; type "show copying" to see the conditions.

2) The toolchain described for debugging of memory leaks and conditional jumps on uninitialized values:

valgrind - http://valgrind.org/docs/manual/QuickStart.html gdb - the GNU debugger

Typical invocation of valgrind: Without looking for uninitialized values (for less output): #valgrind --undef-value-errors=no --leak-check=yes ./geotop ./

You will get output like this: ==21635== 1,504 bytes in 3 blocks are definitely lost in loss record 31 of 75 ==21635== at 0x402601E: malloc (vg_replace_malloc.c:207) ==21635== by 0x80AE9FE: new_longvector (alloc.c:120) ==21635== by 0x80BC63A: read_stringarray (t_io.c:6464) ==21635== by 0x80E37F8: read_keywords (key.palette.c:75) ==21635== by 0x80E3E99: get_filenames_from_keys (get_filenames.c:62) ==21635== by 0x8086041: get_all_input (input.09375.c:98) ==21635== by 0x8079A20: main (geotop.09375.c:117)

Work yourself from the bottom up (here input line input.09375.c:98) until you reach the obvious source for the leak. It always involves heap memory not being freed correctly or not being freed at all.

The tool can be also used for profiling the cache.

3) There needs to be an initialization of the structures allocated in main (only for the non-pointer member variables like ENERGY.dsun, ENERGY.hsun):

TOPO *top; /* topographical characteristics */ SOIL *sl; /* soil characteristics */ LAND *land; /* land characteristics */ WATER *wat; /* water infiltrating */ CHANNEL *cnet; /* channel routing characteristics */ PAR *par; /* various parameters */ ENERGY *egy; /* energy radiation characteristics */ SNOW *snow; /* snow characteristics */ GLACIER *glac; /* glacier characteristics */ METEO *met; /* meteo data characteristics */ TIMES *times; /* time variables */ LISTON *liston; /* structure for Micromet */

4) In order to cover different sources of bugs, we should run GEOtop on different inputs.

Best, Thomas

Emanuele Cordano wrote:list-geotopdev@ing.unitn.it > I start to remove with valgrind some memory leaks from the Boussinesq > code which has similar libraries (functions) to the ones used by > GEOtop. Yesterday I removed more than 100 leakages, a few still > remains in the fluidturtle. A lot of leakage are strickly releted to > bad use of the function join_strings(). In this function (see t_io.c) : > char * join_strings(char *first,char *second) > > { > > char *string; > long len=0; > > > len=strlen(first); > len+=strlen(second)+2; > string=(char *)malloc(len*sizeof(char)); > string=strcpy(string,first); > string=strcat(string,second); > return string; > } > > You can see that the returned string (char*) by the function has been > allocated with malloc. But when we used tit, we never freed this > memory (char *) . I corrected the KeyPalette folder in Boussinesq. > The concatenate ue of join_strings (e.g. char > *a=join_strings(join_strings(ciao,nnn),aaaxxx) ) is a sources of the > memory leakage. They are very spread wherever in the code, especially > I see many in the ASCII folder hat I'm correcting!! > > ciao > Emanuele