This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: [Patch, fortran] Runtime memory leak checking.
- From: dominiq at lps dot ens dot fr (Dominique Dhumieres)
- To: fortran at gcc dot gnu dot org
- Cc: paul dot richard dot thomas at gmail dot com, janus at gcc dot gnu dot org
- Date: Sat, 25 Apr 2009 18:14:22 +0200
- Subject: Re: [Patch, fortran] Runtime memory leak checking.
Hi,
First, thanks for the work and I want to express my strong interest for this
feature: I can tell my colleagues compile with -fcheck=all and tell me the result
rather than go the the Apple developer tool to check memory leak.
I have applied the patch in
http://gcc.gnu.org/ml/fortran/2009-04/msg00226.html
and replaced libgfortran/runtime/memory_check.c by the one in
http://gcc.gnu.org/ml/fortran/2009-04/msg00256.html
Despite this quick and dirty approach, the build went fine excepte the x64
multilib was not updated (I had to reconfigure libgfortran: missing
dependency?). The test gcc/testsuite/gfortran.dg/mem_check_1.f90 gave
Fortran runtime checking: found 2 memory leaks
- at line 7 of file '/opt/gcc/gcc-4.5-work/gcc/testsuite/gfortran.dg/mem_check_1.f90', allocation of 40.0 B (address 0x1002005e0)
- at line 8 of file '/opt/gcc/gcc-4.5-work/gcc/testsuite/gfortran.dg/mem_check_1.f90', allocation of 40.0 B (address 0x100200650)
Peak user-allocated memory: 80.0 B
Peak memory created by the compiler for temporaries: 0.00 B
dyld: lazy symbol binding failed: Symbol not found: _tdestroy
Referenced from: /opt/gcc/gcc4.5w/lib/x86_64/libgfortran.3.dylib
Expected in: dynamic lookup
dyld: Symbol not found: _tdestroy
Referenced from: /opt/gcc/gcc4.5w/lib/x86_64/libgfortran.3.dylib
Expected in: dynamic lookup
Trace/BPT trap
on i686-apple-darwin9. Are the errors "Symbol not found: _tdestroy" a leftover
or am I missing something?
I have also used the option with some polyhedron tests and capacita.f90 and
protein.f90:
Error in memory deallocation at line 137 of source file 'capacita.f90': freeing memory that has not been allocated by us.
Error in memory deallocation at line 2099 of source file 'protein.f90': freeing memory that has not been allocated by us.
I also tried the codes for pr39879 and got:
Setting bunch_params 113 113
Have set
After 1st set
Setting bunch_params 113 113
Have set
a.out(40021) malloc: *** error for object 0x803000: double free
*** set a breakpoint in malloc_error_break to debug
Error in memory deallocation at line 99 of source file 'pr39879_db.f90': freeing memory that has not been allocated by us.
for the original code.
Anything more I can test?
TIA
Dominique