User account creation filtered due to spam.

Bug 38724 - Segfault caused by derived-type with allocatable component in OpenMP private clause
Summary: Segfault caused by derived-type with allocatable component in OpenMP private ...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.4.0
: P3 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: accepts-invalid, openmp
: 40876 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-01-04 19:40 UTC by kargl
Modified: 2015-12-05 23:20 UTC (History)
5 users (show)

See Also:
Host: i386-unknown-freebsd8.0
Target:
Build:
Known to work:
Known to fail: 4.3.3, 4.4.0
Last reconfirmed: 2013-08-12 00:00:00


Attachments
openmp code showing segfault (336 bytes, text/plain)
2009-01-04 19:41 UTC, kargl
Details

Note You need to log in before you can comment on or make changes to this bug.
Description kargl 2009-01-04 19:40:57 UTC
The attached code compiles but dies with a segmentation fault.  If the
omp directive is changed from

!$omp parallel private(k,cell)

to

!$omp parallel private(k)

the code executes.
Comment 1 kargl 2009-01-04 19:41:54 UTC
Created attachment 17030 [details]
openmp code showing segfault
Comment 2 kargl 2009-01-04 19:43:44 UTC
gfc4x -g -o z -O -fopenmp gib.f90

(gdb) run ./z
Starting program: /usr/home/kargl/tmp/z ./z
[New LWP 100056]
[New LWP 100056]
          10          10
           1           1
Assertion failed: (arena != NULL), function arena_dalloc, file /usr/src/lib/libc/stdlib/malloc.c, line 3843.
[New Thread 48103140 (LWP 100056)]

Program received signal SIGABRT, Aborted.
[Switching to Thread 48103140 (LWP 100056)]
0x0808792b in kill ()
(gdb) bt
#0  0x0808792b in kill ()
#1  0x080611e4 in raise ()
#2  0x080867b5 in abort ()
#3  0x0807ac91 in __assert ()
#4  0x08070c5d in idalloc ()
#5  0x08070df7 in free ()
#6  0x0804829c in MAIN__.omp_fn.0 (.omp_data_i=0x0) at gib.f90:31
#7  0x0804867b in test_omp () at gib.f90:29
#8  0x08048709 in main (argc=2, argv=0xbfbfe6f4)
    at ../../../gcc4x/libgfortran/fmain.c:21
Comment 3 kargl 2009-01-04 19:46:02 UTC
Using gfortran 4.3.3, a segfault also occurs but the backtrace is different.

(gdb) run
Starting program: /usr/home/kargl/tmp/z 
[New LWP 100173]
[New Thread 48301140 (LWP 100173)]
          10          10
           1           1

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 48301140 (LWP 100173)]
0x481d5aa3 in malloc_usable_size () from /lib/libc.so.7
(gdb) bt
#0  0x481d5aa3 in malloc_usable_size () from /lib/libc.so.7
#1  0x481d63a7 in free () from /lib/libc.so.7
#2  0x080489c0 in MAIN__.omp_fn.0 (.omp_data_i=0x0) at gib.f90:31
#3  0x08048db2 in test_omp () at gib.f90:5
#4  0x08048e61 in main (argc=Error accessing memory address 0x0: Bad address.
)
    at ../.././..//gcc-4.3-20081120/libgfortran/fmain.c:21
Comment 4 kargl 2009-01-04 19:47:28 UTC
Make the summary a little clear.
Comment 5 Jakub Jelinek 2009-01-04 21:31:19 UTC
OpenMP 3.0 doesn't cover types with allocatable components, so this is undefined.  If anything IMHO we should reject any attempts to privatize
types with allocatable components, because it isn't clear what will OpenMP 4.0
require for them and if we now implement something different, it might be a compatibility problem.
Comment 6 Steve Kargl 2009-01-05 02:32:21 UTC
Subject: Re:  Segfault caused by derived-type with allocatable component in private clause

On Sun, Jan 04, 2009 at 09:31:20PM -0000, jakub at gcc dot gnu dot org wrote:
> 
> ------- Comment #5 from jakub at gcc dot gnu dot org  2009-01-04 21:31 -------
> OpenMP 3.0 doesn't cover types with allocatable components, so this is
> undefined.  If anything IMHO we should reject any attempts to privatize
> types with allocatable components, because it isn't clear what will OpenMP 4.0
> require for them and if we now implement something different, it might be a
> compatibility problem.
> 

OK. Thanks for the info concerning OpenMP 3.0 and allocatable components.
I agree gfortran should reject the program until we have some idea of
the behavior with regards to OpenMP 4.0.

Comment 8 janus 2013-08-12 13:05:36 UTC
(In reply to Steve Kargl from comment #6)
> I agree gfortran should reject the program until we have some idea of
> the behavior with regards to OpenMP 4.0.

It seems that the final OpenMP 4.0 specification does not support allocatable components. In particular it lists "Allocatable enhancement" as unsupported, which supposedly refers to TR 15581 and therefore includes alloc. comp., see

http://openmp.org/wp/openmp-specifications/

So the test case should probably be rejected by the front end (alternatively: support it as a GNU extension).
Comment 9 Dominique d'Humieres 2015-11-03 13:52:24 UTC
Between revisions r211105 (2014-05-31, malloc error) and r211652 (2014-06-13, no run time error) the has started to run without error. The 'fix' has been back ported to 4.9.

> So the test case should probably be rejected by the front end
> (alternatively: support it as a GNU extension).

The code compiles and executes at r229706 (trunk 6.0).

Relate to/duplicate of pr40876?
Comment 10 Dominique d'Humieres 2015-12-05 23:06:46 UTC
> The code compiles and executes at r229706 (trunk 6.0).

Can this PR closed as FIXED?
Comment 11 Dominique d'Humieres 2015-12-05 23:08:57 UTC
*** Bug 40876 has been marked as a duplicate of this bug. ***
Comment 12 Jakub Jelinek 2015-12-05 23:20:54 UTC
Fixed.