http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46210
Summary: segfault when using large arrays with -fopenmp
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: boschm...@tp1.physik.uni-siegen.de
I don't know, whether this is a gcc bug or a openMP bug, but maybe you can
tell. When I use large arrays with dimension > 2**20 and compile with -fopenmp,
then the executable will cause a segmentation fault. The code is:
program mpbug
implicit none
integer,parameter::dim=2**21
integer,dimension(dim)::array
integer::d
forall(d=1:dim)
array(d)=0
end forall
end program mpbug
>gfortran -fopenmp mpbug.f03
>valgrind --leak-check=full `gfortran -v 2>&1 -fopenmp mpbug.f03 | grep f951`
==20196== Memcheck, a memory error detector
==20196== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==20196== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==20196== Command:
/opt/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/f951 mpbug.f03 -quiet
-dumpbase mpbug.f03 -mtune=generic -march=x86-64 -auxbase mpbug -version
-fopenmp -fintrinsic-modules-path
/opt/gcc-trunk/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/finclude -o
/tmp/cc0xLtsi.s
==20196== GNU Fortran (GCC) Version 4.6.0 20101022 (experimental)
(x86_64-unknown-linux-gnu)
kompiliert von GNU-C-Version 4.6.0 20101022 (experimental), GMP version
4.3.1, MPFR version 2.4.2, MPC version 0.8.1
GGC-Heuristik: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU Fortran (GCC) Version 4.6.0 20101022 (experimental)
(x86_64-unknown-linux-gnu)
kompiliert von GNU-C-Version 4.6.0 20101022 (experimental), GMP version
4.3.1, MPFR version 2.4.2, MPC version 0.8.1
GGC-Heuristik: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
==20196==
==20196== HEAP SUMMARY:
==20196== in use at exit: 322,314 bytes in 1,357 blocks
==20196== total heap usage: 3,715 allocs, 2,358 frees, 2,114,876 bytes
allocated
==20196==
==20196== 159 bytes in 1 blocks are definitely lost in loss record 264 of 330
==20196== at 0x4C234E7: calloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==20196== by 0xCEF728: xcalloc (xmalloc.c:162)
==20196== by 0x659964: init_emit (emit-rtl.c:5582)
==20196== by 0x6E68D8: prepare_function_start (function.c:4382)
==20196== by 0x6EC428: init_function_start (function.c:4436)
==20196== by 0x551E6E: trans_function_start.isra.2 (trans-decl.c:2003)
==20196== by 0x55C110: gfc_generate_function_code (trans-decl.c:4563)
==20196== by 0x503B67: gfc_parse_file (parse.c:4243)
==20196== by 0x53B495: gfc_be_parse_file (f95-lang.c:250)
==20196== by 0x839E2F: toplev_main (toplev.c:919)
==20196== by 0x5709A7C: (below main) (libc-start.c:220)
==20196==
==20196== 159 bytes in 1 blocks are definitely lost in loss record 265 of 330
==20196== at 0x4C234E7: calloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==20196== by 0xCEF728: xcalloc (xmalloc.c:162)
==20196== by 0x659964: init_emit (emit-rtl.c:5582)
==20196== by 0x6E68D8: prepare_function_start (function.c:4382)
==20196== by 0x6EC428: init_function_start (function.c:4436)
==20196== by 0x55CAA5: gfc_generate_function_code (trans-decl.c:4315)
==20196== by 0x503B67: gfc_parse_file (parse.c:4243)
==20196== by 0x53B495: gfc_be_parse_file (f95-lang.c:250)
==20196== by 0x839E2F: toplev_main (toplev.c:919)
==20196== by 0x5709A7C: (below main) (libc-start.c:220)
==20196==
==20196== LEAK SUMMARY:
==20196== definitely lost: 318 bytes in 2 blocks
==20196== indirectly lost: 0 bytes in 0 blocks
==20196== possibly lost: 0 bytes in 0 blocks
==20196== still reachable: 321,996 bytes in 1,355 blocks
==20196== suppressed: 0 bytes in 0 blocks
==20196== Reachable blocks (those to which a pointer was found) are not shown.
==20196== To see them, rerun with: --leak-check=full --show-reachable=yes
==20196==
==20196== For counts of detected and suppressed errors, rerun with: -v
==20196== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 4 from 4)
>valgrind --leak-check=full ./a.out
(...)
==20234== Invalid write of size 4
==20234== at 0x400644: MAIN__ (in
/afs/tp1.physik.uni-siegen.de/user/boschmann/tmp/gccbug/openmp/a.out)
==20234== by 0x40068C: main (in
/afs/tp1.physik.uni-siegen.de/user/boschmann/tmp/gccbug/openmp/a.out)
==20234== Address 0x7fe7ffc40 is on thread 1's stack
==20234==
==20234==
==20234== Process terminating with default action of signal 11 (SIGSEGV)
==20234== Access not within mapped region at address 0x7FE7FFC40
==20234== at 0x400644: MAIN__ (in
/afs/tp1.physik.uni-siegen.de/user/boschmann/tmp/gccbug/openmp/a.out)
==20234== If you believe this happened as a result of a stack
==20234== overflow in your program's main thread (unlikely but
==20234== possible), you can try to increase the size of the
==20234== main thread stack using the --main-stacksize= flag.
==20234== The main thread stack size used in this run was 8388608.
==20234==
==20234== Process terminating with default action of signal 11 (SIGSEGV)
==20234== Access not within mapped region at address 0x7FE7FFCB0
==20234== at 0x4A1F5BC: _vgnU_freeres (in
/usr/lib64/valgrind/vgpreload_core-amd64-linux.so)
==20234== If you believe this happened as a result of a stack
==20234== overflow in your program's main thread (unlikely but
==20234== possible), you can try to increase the size of the
==20234== main thread stack using the --main-stacksize= flag.
==20234== The main thread stack size used in this run was 8388608.
==20234==
==20234== HEAP SUMMARY:
==20234== in use at exit: 3,816 bytes in 16 blocks
==20234== total heap usage: 16 allocs, 0 frees, 3,816 bytes allocated
==20234==
==20234== LEAK SUMMARY:
==20234== definitely lost: 0 bytes in 0 blocks
==20234== indirectly lost: 0 bytes in 0 blocks
==20234== possibly lost: 0 bytes in 0 blocks
==20234== still reachable: 3,816 bytes in 16 blocks
==20234== suppressed: 0 bytes in 0 blocks
==20234== Reachable blocks (those to which a pointer was found) are not shown.
==20234== To see them, rerun with: --leak-check=full --show-reachable=yes
==20234==
==20234== For counts of detected and suppressed errors, rerun with: -v
==20234== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 4)
Speicherzugriffsfehler
