[Bug fortran/59589] Memory leak when deallocating polymorphic

2013-12-24 Thread dominiq at lps dot ens.fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59589

--- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr ---
On  x86_64-apple-darwin10.8, gcc version 4.8.2, with the call system line
commented, valgrind gives:

==42524== HEAP SUMMARY:
==42524== in use at exit: 88 bytes in 1 blocks
==42524==   total heap usage: 37 allocs, 36 frees, 400,004,301 bytes allocated
==42524== 
==42524== LEAK SUMMARY:
==42524==definitely lost: 0 bytes in 0 blocks
==42524==indirectly lost: 0 bytes in 0 blocks
==42524==  possibly lost: 0 bytes in 0 blocks
==42524==still reachable: 0 bytes in 0 blocks
==42524== suppressed: 88 bytes in 1 blocks
==42524== 
==42524== For counts of detected and suppressed errors, rerun with: -v
==42524== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

(I don't have valgrind for darwin13).


[Bug fortran/59589] Memory leak when deallocating polymorphic

2013-12-24 Thread dominiq at lps dot ens.fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59589

--- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr ---
The test also succeeds on x86_64-apple-darwin13 (clean r206033 or heavily
patched r206191) when compiled with -fsanitize=leak.


[Bug fortran/59589] Memory leak when deallocating polymorphic

2013-12-24 Thread anlauf at gmx dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59589

Harald Anlauf anlauf at gmx dot de changed:

   What|Removed |Added

 CC||anlauf at gmx dot de

--- Comment #6 from Harald Anlauf anlauf at gmx dot de ---
(In reply to Dominique d'Humieres from comment #4)
 On  x86_64-apple-darwin10.8, gcc version 4.8.2, with the call system line
 commented, valgrind gives:
 
 ==42524== HEAP SUMMARY:
 ==42524== in use at exit: 88 bytes in 1 blocks
 ==42524==   total heap usage: 37 allocs, 36 frees, 400,004,301 bytes
 allocated
 ==42524== 
 ==42524== LEAK SUMMARY:
 ==42524==definitely lost: 0 bytes in 0 blocks
 ==42524==indirectly lost: 0 bytes in 0 blocks
 ==42524==  possibly lost: 0 bytes in 0 blocks
 ==42524==still reachable: 0 bytes in 0 blocks
 ==42524== suppressed: 88 bytes in 1 blocks
 ==42524== 
 ==42524== For counts of detected and suppressed errors, rerun with: -v
 ==42524== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
 
 (I don't have valgrind for darwin13).

On i686-pc-linux-gnu, 4.9.0, and reducing the array size by 1/10, I get:

==31916== HEAP SUMMARY:
==31916== in use at exit: 40,000,000 bytes in 10 blocks
==31916==   total heap usage: 61 allocs, 51 frees, 40,007,249 bytes allocated
==31916== 
==31916== 4,000,000 bytes in 1 blocks are possibly lost in loss record 1 of 2
==31916==at 0x402913D: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==31916==by 0x8049F45: main (test_leak.f90:24)
==31916== 
==31916== 36,000,000 bytes in 9 blocks are definitely lost in loss record 2 of
2
==31916==at 0x402913D: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==31916==by 0x8049F45: main (test_leak.f90:24)
==31916== 
==31916== LEAK SUMMARY:
==31916==definitely lost: 36,000,000 bytes in 9 blocks
==31916==indirectly lost: 0 bytes in 0 blocks
==31916==  possibly lost: 4,000,000 bytes in 1 blocks
==31916==still reachable: 0 bytes in 0 blocks
==31916== suppressed: 0 bytes in 0 blocks


[Bug fortran/59589] Memory leak when deallocating polymorphic

2013-12-24 Thread dominiq at lps dot ens.fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59589

Dominique d'Humieres dominiq at lps dot ens.fr changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #7 from Dominique d'Humieres dominiq at lps dot ens.fr ---
 On i686-pc-linux-gnu, 4.9.0, and reducing the array size by 1/10, I get: ...

So confirmed. It looks like something is not properly initialized.


[Bug fortran/59589] Memory leak when deallocating polymorphic

2013-12-24 Thread anlauf at gmx dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59589

--- Comment #8 from Harald Anlauf anlauf at gmx dot de ---
No lag with 4.8.0 (or 4.7.x) on same machine:

==8545== HEAP SUMMARY:
==8545== in use at exit: 0 bytes in 0 blocks
==8545==   total heap usage: 41 allocs, 41 frees, 40,007,187 bytes allocated
==8545== 
==8545== All heap blocks were freed -- no leaks are possible


So it's actually a regression.


[Bug fortran/59589] Memory leak when deallocating polymorphic

2013-12-23 Thread townsend at astro dot wisc.edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59589

--- Comment #1 from Rich Townsend townsend at astro dot wisc.edu ---
Oops, missed out details. This is with rev. 206179, on both OS X and Linux.


[Bug fortran/59589] Memory leak when deallocating polymorphic

2013-12-23 Thread dominiq at lps dot ens.fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59589

Dominique d'Humieres dominiq at lps dot ens.fr changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2013-12-24
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr ---
Works for me on OS X for 4.8.2 or trunk. What command are you using?


[Bug fortran/59589] Memory leak when deallocating polymorphic

2013-12-23 Thread townsend at astro dot wisc.edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59589

--- Comment #3 from Rich Townsend townsend at astro dot wisc.edu ---
(In reply to Dominique d'Humieres from comment #2)
 Works for me on OS X for 4.8.2 or trunk. What command are you using?

townsend@talos ~ $ gfortran -v
Using built-in specs.
COLLECT_GCC=/Applications/madsdk/bin/gfortran.exec
COLLECT_LTO_WRAPPER=/Applications/madsdk/libexec/gcc/x86_64-apple-darwin11.4.2/4.9.0/lto-wrapper
Target: x86_64-apple-darwin11.4.2
Configured with: ./configure CC='gcc -D_FORTIFY_SOURCE=0'
--build=x86_64-apple-darwin11.4.2 --prefix=/Applications/madsdk
--with-gmp=/Applications/madsdk --with-mpfr=/Applications/madsdk
--with-mpc=/Applications/madsdk --enable-languages=c,c++,fortran
--disable-multilib --disable-nls --disable-libsanitizer
Thread model: posix
gcc version 4.9.0 20131223 (experimental) (GCC) 

townsend@talos ~ $ gfortran -o test_leak test_leak.f90 

townsend@talos ~ $ ./test_leak 
./test_leak  39688
./test_leak  78764
./test_leak 117828
./test_leak 156908
./test_leak 195972
./test_leak 235036
./test_leak 274100
./test_leak 313164
./test_leak 352228
./test_leak 391292

...so, the memory usage grows on each iteration of the loop; this suggests a
leak.