[Bug fortran/58425] New: Finalization: Segfault at runtime

[Bug fortran/58425] New: Finalization: Segfault at runtime

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58425

            Bug ID: 58425
           Summary: Finalization: Segfault at runtime
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Keywords: wrong-code
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: burnus at gcc dot gnu.org

The code at ssdSource/chapter05/hermetic of http://www.cambridge.org/rouson
fails at run-time with:

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.
#3  0x401169 in __vortex_module_MOD_finalize
#4  0x400D92 in __vortex_module_MOD___final_vortex_module_Vortex
#5  0x4011C9 in __vortex_module_MOD_finalize
#6  0x400D92 in __vortex_module_MOD___final_vortex_module_Vortex
#7  0x401138 in __vortex_module_MOD_manual_finalizer
#8  0x400B37 in MAIN__ at main.F90:?


It works with other compilers. (As finalization is new, it doesn't count as
regression.)

[Bug fortran/58425] Finalization: Segfault at runtime

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58425

--- Comment #1 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Works for me:

[macbook] f90/bug% gfcc ~/test/Rouson/ssdSource/chapter05/hermetic/hermetic.F90
-c -Ofast
[macbook] f90/bug% gfcc ~/test/Rouson/ssdSource/chapter05/hermetic/vortex.F90
-c -Ofast
[macbook] f90/bug% gfcc ~/test/Rouson/ssdSource/chapter05/hermetic/main.F90
hermetic.o vortex.o -Ofast
[macbook] f90/bug% a.out
   1.00000000       0.00000000       0.00000000    
  0.707106769      0.707106769       0.00000000    
  -4.37113883E-08   1.00000000       0.00000000    
 -0.707106769      0.707106769       0.00000000    
  -1.00000000      -8.74227766E-08   0.00000000    
 -0.707106650     -0.707106888       0.00000000    
   1.19248806E-08  -1.00000000       0.00000000    
  0.707107008     -0.707106531       0.00000000    
[macbook] f90/bug% gfcc -v
Using built-in specs.
COLLECT_GCC=gfcc
COLLECT_LTO_WRAPPER=/opt/gcc/gcc4.9c/libexec/gcc/x86_64-apple-darwin10.8.0/4.9.0/lto-wrapper
Target: x86_64-apple-darwin10.8.0
Configured with: ../_clean/configure --prefix=/opt/gcc/gcc4.9c
--enable-languages=c,c++,fortran,objc,obj-c++,java,ada,lto --with-gmp=/opt/mp
--with-system-zlib --with-isl=/opt/mp --enable-lto --enable-plugin
Thread model: posix
gcc version 4.9.0 20130914 (experimental) [trunk revision 202590] (GCC) 

I also get the same output with -flto added or without -Ofast.

[Bug fortran/58425] Finalization: Segfault at runtime

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58425

--- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> ---
The code works when one adds a line to vortex.F90's manual_finalizer:

    do while(associated(current%next))
      next => current%next ! start after break in chain
      deallocate(current)
      current=>next
      if (.not.associated(current)) exit ! <<<< ADDED
    end do

Thus, at least locally, the program has a bug. The other question is whether
for the specific program, it should still work. At least with Crayftn, it seems
to work (also with valgring/MALLOC_PERTURB_ set). On the other hand, with ifort
it starts failing when MALLOC_PERTURB_ is set.

[Bug fortran/58425] Finalization: Segfault at runtime

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58425

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to Tobias Burnus from comment #2)
> At least with Crayftn, it seems to work (also with valgring/MALLOC_PERTURB_
> set).

Same result with pgf90 13.4-0. Additionally, I re-checked it with "ftn
-dynamic" and valgrind, which prints:
craylibs//google-perftools/src/tcmalloc.cc:632] Attempt to free invalid
pointer: 0x4084520

Thus, I close the bug as INVALID without having tried to investigate where the
bug occurs.

ALL: If you have reason to believe that it is (still) a compiler bug, feel free
to re-open the PR.