gfortran -fstack-check valgrind Segmentation fault

[Tobias Burnus]

On 02/09/2012 10:27 AM, José Rui Faustino Sousa wrote:
> I am not sure if this should go to valgrind or to gfortran, so it goes
> both ways... ;-)

It works for me with
   gcc version 4.7.0 20120209 (experimental) [trunk revision 184033] (GCC)
and valgrind-3.7.0 on a x86_64 Linux system:

$ gfortran -g -fstack-check test.f90 && valgrind --tool=memcheck ./a.out
==19319== Memcheck, a memory error detector
==19319== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==19319== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==19319== Command: ./a.out
==19319==
==19319==
==19319== HEAP SUMMARY:
==19319==     in use at exit: 0 bytes in 0 blocks
==19319==   total heap usage: 21 allocs, 21 frees, 11,967 bytes allocated
==19319==
==19319== All heap blocks were freed -- no leaks are possible
==19319==
==19319== For counts of detected and suppressed errors, rerun with: -v
==19319== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)


I get the same result with GCC 4.5 and 4.6.

> $ gfortran --version
> GNU Fortran (Ubuntu 4.4.3-4ubuntu5) 4.4.3

I do see a failure with GCC 4.4:

==19406== Invalid write of size 8
==19406==    at 0x4006E8: MAIN__ (in /dev/shm/a.out)
==19406==    by 0x400739: main (fmain.c:21)
==19406==  Address 0x7feffce18 is not stack'd, malloc'd or (recently) free'd
==19406==
==19406== Process terminating with default action of signal 11 
(SIGSEGV): dumping core
==19406==  Access not within mapped region at address 0x7FEFFCE18
==19406==    at 0x4006E8: MAIN__ (in /dev/shm/a.out)
==19406==    by 0x400739: main (fmain.c:21)


My suspicion is that the failure is somehow related to the way gfortran 
has handed the main program before GCC 4.5:

For the main PROGRAM, the Fortran compiler created procedure - 
internally called "MAIN__" and linked the actual main program, which did 
some setup work and then called "MAIN__". (That's how some other 
compilers do it as well.)

Since 4.5, gfortran not only generates the "MAIN__" function (the name 
has to stay there because of backward compatibility) but also the "main" 
function, which does the initialization of the run-time library before 
calling MAIN__.


I think the -fstack-check somehow interacts badly with having an 
externally linked "main". I don't know why - and I am actually not 
inclined to find out what -fstack-check exactly does.

Tobias