public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/56471] New: Program crashes when allocating a derived type with a character allocatable array component.
@ 2013-02-27 10:19 vladimir.fuka at gmail dot com
  2013-02-27 11:55 ` [Bug fortran/56471] Program crashes when allocating a derived type with an allocatable component janus at gcc dot gnu.org
                   ` (3 more replies)
  0 siblings, 4 replies; 5+ messages in thread
From: vladimir.fuka at gmail dot com @ 2013-02-27 10:19 UTC (permalink / raw)
  To: gcc-bugs


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

             Bug #: 56471
           Summary: Program crashes when allocating a derived type with a
                    character allocatable array component.
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: vladimir.fuka@gmail.com


Created attachment 29547
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29547
reproduction source file

The attached program crashes when executing the allocate statement. Originally
reported in
http://stackoverflow.com/questions/15107976/why-does-the-following-fortran-code-allocate-on-the-stack-heap-depending-on-the

gfortran -v allocate.f90 -fcheck=all -fbacktrace -g -gdwarf-3
Driving: gfortran -v allocate.f90 -fcheck=all -fbacktrace -g -gdwarf-3 -l
gfortran -l m -shared-libgcc
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/local/gcc-4.8/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.8-20130224/configure --enable-languages=c,c++,fortran
--with-cloog --prefix=/usr/local/gcc-4.8
Thread model: posix
gcc version 4.8.0 20130224 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-v' '-fcheck=all' '-fbacktrace' '-g' '-gdwarf-3'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/local/gcc-4.8/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/f951 allocate.f90
-quiet -dumpbase allocate.f90 -mtune=generic -march=x86-64 -auxbase allocate -g
-gdwarf-3 -version -fcheck=all -fbacktrace -fintrinsic-modules-path
/usr/local/gcc-4.8/lib64/gcc/x86_64-unknown-linux-gnu/4.8.0/finclude -o
/tmp/cc6wTJXo.s
GNU Fortran (GCC) version 4.8.0 20130224 (experimental)
(x86_64-unknown-linux-gnu)
        compiled by GNU C version 4.8.0 20130224 (experimental), GMP version
5.0.5, MPFR version 3.1.0-p1, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU Fortran (GCC) version 4.8.0 20130224 (experimental)
(x86_64-unknown-linux-gnu)
        compiled by GNU C version 4.8.0 20130224 (experimental), GMP version
5.0.5, MPFR version 3.1.0-p1, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
COLLECT_GCC_OPTIONS='-v' '-fcheck=all' '-fbacktrace' '-g' '-gdwarf-3'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
 as -v --64 -o /tmp/ccSfTbSl.o /tmp/cc6wTJXo.s
GNU assembler version 2.22 (x86_64-suse-linux) using BFD version (GNU Binutils;
openSUSE 12.2) 2.22
Reading specs from
/usr/local/gcc-4.8/lib64/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../lib64/libgfortran.spec
rename spec lib to liborig
COLLECT_GCC_OPTIONS='-v' '-fcheck=all' '-fbacktrace' '-g' '-gdwarf-3'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
COMPILER_PATH=/usr/local/gcc-4.8/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/:/usr/local/gcc-4.8/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/:/usr/local/gcc-4.8/lib/gcc/x86_64-unknown-linux-gnu/:/usr/local/gcc-4.8/lib64/gcc/x86_64-unknown-linux-gnu/4.8.0/:/usr/local/gcc-4.8/lib64/gcc/x86_64-unknown-linux-gnu/
LIBRARY_PATH=/usr/local/gcc-4.8/lib64/gcc/x86_64-unknown-linux-gnu/4.8.0/:/usr/local/gcc-4.8/lib64/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/opt/intel/composer_xe_2013.1.117/compiler/lib/intel64/:/opt/intel/composer_xe_2013.1.117/ipp/../compiler/lib/intel64/:/opt/intel/composer_xe_2013.1.117/ipp/lib/intel64/:/opt/intel/composer_xe_2013.1.117/compiler/lib/intel64/:/opt/intel/composer_xe_2013.1.117/mkl/lib/intel64/:/opt/intel/composer_xe_2013.1.117/tbb/lib/intel64/:/usr/local/gcc-4.8/lib64/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-fcheck=all' '-fbacktrace' '-g' '-gdwarf-3'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/local/gcc-4.8/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/collect2
--eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2
/usr/lib/../lib64/crt1.o /usr/lib/../lib64/crti.o
/usr/local/gcc-4.8/lib64/gcc/x86_64-unknown-linux-gnu/4.8.0/crtbegin.o
-L/usr/local/gcc-4.8/lib64/gcc/x86_64-unknown-linux-gnu/4.8.0
-L/usr/local/gcc-4.8/lib64/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../lib64
-L/lib/../lib64 -L/usr/lib/../lib64
-L/opt/intel/composer_xe_2013.1.117/compiler/lib/intel64
-L/opt/intel/composer_xe_2013.1.117/ipp/../compiler/lib/intel64
-L/opt/intel/composer_xe_2013.1.117/ipp/lib/intel64
-L/opt/intel/composer_xe_2013.1.117/compiler/lib/intel64
-L/opt/intel/composer_xe_2013.1.117/mkl/lib/intel64
-L/opt/intel/composer_xe_2013.1.117/tbb/lib/intel64
-L/usr/local/gcc-4.8/lib64/gcc/x86_64-unknown-linux-gnu/4.8.0/../../..
/tmp/ccSfTbSl.o -lgfortran -lm -lgcc_s -lgcc -lquadmath -lm -lgcc_s -lgcc -lc
-lgcc_s -lgcc
/usr/local/gcc-4.8/lib64/gcc/x86_64-unknown-linux-gnu/4.8.0/crtend.o
/usr/lib/../lib64/crtn.o



:~/f/errors> ./a.out 
Neoprávněný přístup do paměti (SIGSEGV)


^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Bug fortran/56471] Program crashes when allocating a derived type with an allocatable component
  2013-02-27 10:19 [Bug fortran/56471] New: Program crashes when allocating a derived type with a character allocatable array component vladimir.fuka at gmail dot com
@ 2013-02-27 11:55 ` janus at gcc dot gnu.org
  2013-06-29 21:55 ` dominiq at lps dot ens.fr
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 5+ messages in thread
From: janus at gcc dot gnu.org @ 2013-02-27 11:55 UTC (permalink / raw)
  To: gcc-bugs


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

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |janus at gcc dot gnu.org
            Summary|Program crashes when        |Program crashes when
                   |allocating a derived type   |allocating a derived type
                   |with a character            |with an allocatable
                   |allocatable array           |component
                   |component.                  |

--- Comment #1 from janus at gcc dot gnu.org 2013-02-27 11:55:37 UTC ---
Reduced test case:

program main
  implicit none    
    type :: containerType
    real, dimension(10000000) ::  arrayData 
    integer, allocatable :: allo
  end type
  type (containerType),allocatable :: container
  allocate(container)
end program


Note: The allocatable component does not have to be CHARACTER, but the array
needs to be very large in order to trigger the error. The generated code is:

      container = 0B;
      if ((logical(kind=4)) __builtin_expect ((integer(kind=8)) (container !=
0B), 0))
        {
          _gfortran_runtime_error_at (...);
        }
      else
        {
          container = (struct containertype *) __builtin_malloc (40000008);
          if ((logical(kind=4)) __builtin_expect ((integer(kind=8)) (container
== 0B), 0))
            {
              _gfortran_os_error (...);
            }
        }
      container->allo = 0B;
      {
        struct containertype containertype.0;

        if (container != 0B) goto L.1;
        container = (struct containertype *) __builtin_calloc (1, 40000008);
        L.1:;
        containertype.0.allo = 0B;
        *container = containertype.0;
      }


I don't really understand why 'container' is being allocated twice: Once with
__builtin_malloc and once with __builtin_calloc. Looks like we're leaking
memory here.

Valgrind reports:

==28612== Warning: client switching stacks?  SP change: 0x7fefffbe0 -->
0x7fc9da1d0
==28612==          to suppress, use: --max-stackframe=40000016 or greater
==28612== Invalid write of size 8
==28612==    at 0x4008E5: MAIN__ (in /home/jweil/GSoC/PRs/56471/a.out)
==28612==    by 0x4009D2: main (in /home/jweil/GSoC/PRs/56471/a.out)
==28612==  Address 0x7fc9da1c8 is on thread 1's stack
==28612== 
==28612== Can't extend stack to 0x7fc9d95e0 during signal delivery for thread
1:
==28612==   no stack segment
==28612== 
==28612== Process terminating with default action of signal 11 (SIGSEGV)
==28612==  Access not within mapped region at address 0x7FC9D95E0
==28612==    at 0x4008E5: MAIN__ (in /home/jweil/GSoC/PRs/56471/a.out)
==28612==  If you believe this happened as a result of a stack
==28612==  overflow in your program's main thread (unlikely but
==28612==  possible), you can try to increase the size of the
==28612==  main thread stack using the --main-stacksize= flag.
==28612==  The main thread stack size used in this run was 8388608.


Indeed the segfault seems to be due to a stack overflow.


^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Bug fortran/56471] Program crashes when allocating a derived type with an allocatable component
  2013-02-27 10:19 [Bug fortran/56471] New: Program crashes when allocating a derived type with a character allocatable array component vladimir.fuka at gmail dot com
  2013-02-27 11:55 ` [Bug fortran/56471] Program crashes when allocating a derived type with an allocatable component janus at gcc dot gnu.org
@ 2013-06-29 21:55 ` dominiq at lps dot ens.fr
  2015-10-24 15:11 ` Joost.VandeVondele at mat dot ethz.ch
  2020-07-31 22:45 ` etienne.pellegrini at jpl dot nasa.gov
  3 siblings, 0 replies; 5+ messages in thread
From: dominiq at lps dot ens.fr @ 2013-06-29 21:55 UTC (permalink / raw)
  To: gcc-bugs

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-06-29
     Ever confirmed|0                           |1


^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Bug fortran/56471] Program crashes when allocating a derived type with an allocatable component
  2013-02-27 10:19 [Bug fortran/56471] New: Program crashes when allocating a derived type with a character allocatable array component vladimir.fuka at gmail dot com
  2013-02-27 11:55 ` [Bug fortran/56471] Program crashes when allocating a derived type with an allocatable component janus at gcc dot gnu.org
  2013-06-29 21:55 ` dominiq at lps dot ens.fr
@ 2015-10-24 15:11 ` Joost.VandeVondele at mat dot ethz.ch
  2020-07-31 22:45 ` etienne.pellegrini at jpl dot nasa.gov
  3 siblings, 0 replies; 5+ messages in thread
From: Joost.VandeVondele at mat dot ethz.ch @ 2015-10-24 15:11 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56471

Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2013-06-29 00:00:00         |2015-10-24
                 CC|                            |Joost.VandeVondele at mat dot ethz
                   |                            |.ch
      Known to fail|                            |6.0

--- Comment #2 from Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> ---
yes, stack overflow also with trunk.

> gfortran -fsanitize=address -g PR56471.f90 && ./a.out
ASAN:DEADLYSIGNAL
=================================================================
==13127==ERROR: AddressSanitizer: stack-overflow on address 0x7ffe797483b8 (pc
0x000000400b73 bp 0x7ffe7bd6ddd0 sp 0x7ffe797483b0 T0)
    #0 0x400b72 in MAIN__ /data/vjoost/gnu/bugs/PR56471.f90:2
    #1 0x400d0a in main /data/vjoost/gnu/bugs/PR56471.f90:10
    #2 0x3ba4a1ed5c in __libc_start_main (/lib64/libc.so.6+0x3ba4a1ed5c)
    #3 0x400a78  (/data/vjoost/gnu/bugs/a.out+0x400a78)

SUMMARY: AddressSanitizer: stack-overflow /data/vjoost/gnu/bugs/PR56471.f90:2
in MAIN__
==13127==ABORTING


^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Bug fortran/56471] Program crashes when allocating a derived type with an allocatable component
  2013-02-27 10:19 [Bug fortran/56471] New: Program crashes when allocating a derived type with a character allocatable array component vladimir.fuka at gmail dot com
                   ` (2 preceding siblings ...)
  2015-10-24 15:11 ` Joost.VandeVondele at mat dot ethz.ch
@ 2020-07-31 22:45 ` etienne.pellegrini at jpl dot nasa.gov
  3 siblings, 0 replies; 5+ messages in thread
From: etienne.pellegrini at jpl dot nasa.gov @ 2020-07-31 22:45 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56471

Etienne Pellegrini <etienne.pellegrini at jpl dot nasa.gov> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |etienne.pellegrini at jpl dot nasa
                   |                            |.gov

--- Comment #4 from Etienne Pellegrini <etienne.pellegrini at jpl dot nasa.gov> ---
This bug is reconfirmed with gcc-10.2.0, using Vladimir Fuka's reproduction
source file.

$ gfortran -v allocate.f90 -fcheck=all -fbacktrace -g -gdwarf-3
Driving: gfortran -v allocate.f90 -fcheck=all -fbacktrace -g -gdwarf-3 -l
gfortran -l m -shared-libgcc
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/home/etiennes/.local/libexec/gcc/x86_64-pc-linux-gnu/10.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../../src/gcc-10.2.0/configure
--prefix=/home/etiennes/.local/opt/gcc-10.2.0
--exec-prefix=/home/etiennes/.local
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.2.0 (GCC)
COLLECT_GCC_OPTIONS='-v' '-fcheck=all' '-fbacktrace' '-g' '-gdwarf-3'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /home/etiennes/.local/libexec/gcc/x86_64-pc-linux-gnu/10.2.0/f951 allocate.f90
-quiet -dumpbase allocate.f90 -mtune=generic -march=x86-64 -auxbase allocate -g
-gdwarf-3 -version -fcheck=all -fbacktrace -fintrinsic-modules-path
/home/etiennes/.local/lib/gcc/x86_64-pc-linux-gnu/10.2.0/finclude -o
/tmp/ccM11kGs.s
GNU Fortran (GCC) version 10.2.0 (x86_64-pc-linux-gnu)
        compiled by GNU C version 10.2.0, GMP version 6.1.0, MPFR version
3.1.4, MPC version 1.0.3, isl version isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Fortran2008 (GCC) version 10.2.0 (x86_64-pc-linux-gnu)
        compiled by GNU C version 10.2.0, GMP version 6.1.0, MPFR version
3.1.4, MPC version 1.0.3, isl version isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
COLLECT_GCC_OPTIONS='-v' '-fcheck=all' '-fbacktrace' '-g' '-gdwarf-3'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
 as -v --64 -o /tmp/ccm2HDAF.o /tmp/ccM11kGs.s
GNU assembler version 2.25.1 (x86_64-redhat-linux) using BFD version version
2.25.1-32.base.el7_4.1
Reading specs from
/home/etiennes/.local/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../lib64/libgfortran.spec
rename spec lib to liborig
COLLECT_GCC_OPTIONS='-v' '-fcheck=all' '-fbacktrace' '-g' '-gdwarf-3'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
COMPILER_PATH=/home/etiennes/.local/libexec/gcc/x86_64-pc-linux-gnu/10.2.0/:/home/etiennes/.local/libexec/gcc/x86_64-pc-linux-gnu/10.2.0/:/home/etiennes/.local/libexec/gcc/x86_64-pc-linux-gnu/:/home/etiennes/.local/lib/gcc/x86_64-pc-linux-gnu/10.2.0/:/home/etiennes/.local/lib/gcc/x86_64-pc-linux-gnu/
LIBRARY_PATH=/home/etiennes/.local/lib/gcc/x86_64-pc-linux-gnu/10.2.0/:/home/etiennes/.local/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/home/etiennes/.local/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-fcheck=all' '-fbacktrace' '-g' '-gdwarf-3'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /home/etiennes/.local/libexec/gcc/x86_64-pc-linux-gnu/10.2.0/collect2 -plugin
/home/etiennes/.local/libexec/gcc/x86_64-pc-linux-gnu/10.2.0/liblto_plugin.so
-plugin-opt=/home/etiennes/.local/libexec/gcc/x86_64-pc-linux-gnu/10.2.0/lto-wrapper
-plugin-opt=-fresolution=/tmp/ccpR7PBS.res -plugin-opt=-pass-through=-lgcc_s
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lquadmath
-plugin-opt=-pass-through=-lm -plugin-opt=-pass-through=-lgcc_s
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc
--eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2
/lib/../lib64/crt1.o /lib/../lib64/crti.o
/home/etiennes/.local/lib/gcc/x86_64-pc-linux-gnu/10.2.0/crtbegin.o
-L/home/etiennes/.local/lib/gcc/x86_64-pc-linux-gnu/10.2.0
-L/home/etiennes/.local/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../lib64
-L/lib/../lib64 -L/usr/lib/../lib64
-L/home/etiennes/.local/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../..
/tmp/ccm2HDAF.o -lgfortran -lm -lgcc_s -lgcc -lquadmath -lm -lgcc_s -lgcc -lc
-lgcc_s -lgcc /home/etiennes/.local/lib/gcc/x86_64-pc-linux-gnu/10.2.0/crtend.o
/lib/../lib64/crtn.o
COLLECT_GCC_OPTIONS='-v' '-fcheck=all' '-fbacktrace' '-g' '-gdwarf-3'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'

$ ./a.out
Segmentation fault

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2020-07-31 22:45 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-02-27 10:19 [Bug fortran/56471] New: Program crashes when allocating a derived type with a character allocatable array component vladimir.fuka at gmail dot com
2013-02-27 11:55 ` [Bug fortran/56471] Program crashes when allocating a derived type with an allocatable component janus at gcc dot gnu.org
2013-06-29 21:55 ` dominiq at lps dot ens.fr
2015-10-24 15:11 ` Joost.VandeVondele at mat dot ethz.ch
2020-07-31 22:45 ` etienne.pellegrini at jpl dot nasa.gov

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).