segmentation fault with derived types

[galtay]

hello everyone,

Im getting a segmentation fault from the code below compiled with version 10 of ifort. the only flag im using is -stand to make sure that everything is portable.

*********************************************************
program precision
implicit none
integer, parameter :: sp = selected_real_kind(6,37)
integer, parameter :: dp = selected_real_kind(15,307)
integer, parameter :: qp = selected_real_kind(33,4931)

type particle
real(sp) :: h
real(sp) :: V
end type particle

type particle_system
integer :: n
real(sp) :: r
type(particle), allocatable :: par(:)
end type particle_system

integer :: N,i
integer :: aerr
type(particle_system) :: psys

N = 150**3
write(*,*) "N = ", N

psys%n = N
psys%r = 12.5
allocate( psys%par(N) ,stat=aerr)
if (aerr/=0) stop "cant allocate psys%par"
write(*,*) "allocated particle system"

psys%par(:)%h = 1.0

do i = 1,N
psys%par(i)%h = psys%par(i)%h * 2
end do
write(*,*) "ran loop"

psys%par(:)%h = psys%par(:)%h * 2


end program precision
********************************************************


the code runs up to the write statement which says "ran loop" then produces a seg fault while trying to accomplish the line just after the write statement (which does the same thing, just without a do loop). I dont know if it has something to do with the derived types because it doesn't seg fault for smaller values of N (the size of the array par). It whole array assignment does work with arrays that are not components of derived types ie ( h = 2 * h) would work with the proper declarations. It also compiles and runs fine with the free g95 compiler. Does anyone have some insight into what is actually happening behind the scenes when the whole array operations are invoked? Any ideas about what is causing the seg fault? Thanks for your time,

Gabe

[Steven_L_Intel1]

The compiler is probably creating a stack temporary and running out of stack. Try raising your stacksize limit or compile with -heap-arrays.

[jimdempseyatthecove]

Steve,

>> The compiler is probably creating a stack temporary and running out of stack. Try raising your stacksize limit or compile with -heap-arrays.

The problem is the compiler is creating an unnecessary stack temporary to hold the array of structures.

The user should submit this to Intel Premier Support.

Jim

[Steven_L_Intel1]

I agree with Jim - please submit this to Intel Premier Support and indicate that the last assignment statement ought not to generate array temporary copies.

[galtay]

I'll submit it to premier support (how do i do that by the way?) I always wondered how much of a performance hit i was taking when trying to pull whole array operations on components of derived types that are allocatable arrays. I could code this project in such a way where all the arrays are stand alone, but the organizational headache would be pretty big. I also plan on parallelizing this thing later with MPI and Im starting to get nervous about the derived types. Anyone know the dangers/pleasures of passing derived types through MPI?

[galtay]

I got the issue submitted to premier support (of course, the form was one search away). It asked me what version of glibc i was using and i recalled that mine is a bit newer than what was claimed to be supported in the installation so maybe the problem lies there. No more brand new operating systems or libraries for me.

[TimP]

No problem with testing and reporting issues on a slightly newer glibc than what the compiler was tested with. If your issue should turn out to be associated with the newer glibc, it still is important to deal with it in a timely fashion. Of course, you aren't obligated to be part of the leading edge.

[jimdempseyatthecove]

>> I agree with Jim - please submit this to Intel Premier Support and indicate that the last assignment statement ought not to generate array temporary copies.

Also put in a gripe to request that a compiler option be available to report on instances of temporary array creation. These buggers are hard to spot except for when you use a profiler or happen to stumble into the code in Disassembly window. BTW there is a runtime option to make such a reportbut I found this of little use as the "traceback" info is insufficient. The place to catch the problem is at compile time.

Jim

[Steven_L_Intel1]

Derived types are not pointers - they're "structs" if you want a C analogy. However, a derived type component that is ALLOCATEABLE or POINTER is a pointer - how "fancy" it is depends on whether the item is a scalar or an array.

[Steven_L_Intel1]

An allocatable array component is a pointer plus shape information (rank, bounds) plus some flags. Allocating the array larger doesn't change the size of the component, so in this context, that the array is in a derived type ought not to be relevant.

Now there are cases where the compiler thinks it might need to create a temporary copy of an array. In many cases where a copy is in fact not required the compiler figures this out, but allocatable arrays in derived types have interesting semantics on assignment and the compiler might not always remove unnecessary copies. This could manifest itself as segfaults due to stack overflow. Compiling with -heap-arrays can help with this.