topic Re: Weird Segmentation Fault in Intel® Fortran Compiler

Weird Segmentation Fault

riccardi — Fri, 23 Jan 2009 22:18:00 GMT

Hello All,

I'm running into a weird segmentation fault (forrtl: severe (174): SIGSEGV) that has left me nonplussed. I have a Data Type that stores a bunch of complex vectors, dimension = 3, and a simple subroutine for printing a 3D complex wavevectors. Looping over each vector in the data type, if I send the vector to the subroutine via the data type, it fails; if I copy the data type vector it into another complex vector(3) and send that, it works.

! THIS FAILS

do i = 1, branches%natoms

call z_onebythree_print(branches%branch(1)%atdisp(i)%zvec)

end do

! THIS WORKS

do i = 1, branches%natoms

zvec = branches%branch(1)%atdisp(i)%zvec

call z_onebythree_print(zvec)

end do

**************

subroutine z_onebythree_print(zvec)

complex(kind=8), intent(in) :: zvec(3)

character(len=1) :: xchar,ychar,zchar

xchar="+"

ychar="+"

zchar="+"

if(dimag(zvec(1)).lt. zero) xchar = "-"

if(dimag(zvec(2)).lt. zero) ychar = "-"

if(dimag(zvec(3)).lt. zero) zchar = "-"

print '(F10.4,a1,F6.4,a1,F10.4,a1,F6.4,a1,F10.4,a1,F6.4,a1)',&

dble(zvec(1)),xchar,abs(dimag(zvec(1))), "i", &

dble(zvec(2)),ychar,abs(dimag(zvec(2))), "i", &

dble(zvec(3)),zchar,abs(dimag(zvec(3))), "i"

end subroutine

*************

Please let me know if you have any ideas!

Thank you.

Demian

Re: Weird Segmentation Fault

Ron_Green — Fri, 23 Jan 2009 22:57:07 GMT

You did read the various threads on this forum for sigsegv, segmentation fault, etc, right? And you tried ALL the options mentioned?

What version of the compiler are you using? I cannot reproduce this with 11.0 on Mac OS X. Below is my testcase. I highly recommend the previous suggestions on this post regarding
-gen-interfaces -warn interfaces

and also options

-check all -g -traceback -O2 -fp-stack-check

Something is different with your code that is not captured with the case below. If you disagree, please open a problem report at premier.intel.com including your code and instructions on how to run it.

--- repro.f90 ---
program repro
implicit none
complex (kind=8) :: zvec(3)

type zztopvec
complex (kind=8) :: zvec(3)
end type

type attilla
type (zztopvec) :: atdisp(3)
end type attilla

type immabranch
type (attilla) :: branch(3)
end type

type (immabranch) :: branches

integer :: i

print*, "entering case 1"
do i=1,3
call z_onebythree_print(branches%branch(1)%atdisp(i)%zvec)
end do

print*, "exiting case 1 OK"
print*, " "
print*, "entering case 2"

do i=1,3
zvec = branches%branch(1)%atdisp(i)%zvec
call z_onebythree_print( zvec )
end do
print*, "exiting case 2 OK"

contains

subroutine z_onebythree_print(zvec)
complex(kind=8), intent(in) :: zvec(3)
character(len=1) :: xchar,ychar,zchar

print*, "made it into sub"

end subroutine z_onebythree_print
end program repro

--- end file ---

output
rwgreen-mac01:63141 rwgreen$ ifort -o repro -g -traceback repro.f90
rwgreen-mac01:63141 rwgreen$ ./repro
entering case 1
made it into sub
made it into sub
made it into sub
exiting case 1 OK

entering case 2
made it into sub
made it into sub
made it into sub

Re: Weird Segmentation Fault

riccardi — Fri, 23 Jan 2009 23:33:23 GMT

Quoting - Ronald Green (Intel)

You did read the various threads on this forum for sigsegv, segmentation fault, etc, right? And you tried ALL the options mentioned?

You're right, I should have looked at more threads first as before you responded I did find some useful suggestions. I still haven't found the answer though.

What version of the compiler are you using? I cannot reproduce this with 11.0 on Mac OS X. Below is my testcase. I highly recommend the previous suggestions on this post regarding
-gen-interfaces -warn interfaces

10.0

and also options

-check all -g -traceback -O2 -fp-stack-check

Something is different with your code that is not captured with the case below. If you disagree, please open a problem report at premier.intel.com including your code and instructions on how to run it.

I'm getting ald: fatal error in /usr/bin/ld64 with the -g.. I'm going to talk to the admin

--- repro.f90 ---
program repro
implicit none
complex (kind=8) :: zvec(3)

type zztopvec
complex (kind=8) :: zvec(3)
end type

type attilla
type (zztopvec) :: atdisp(3)
end type attilla

type immabranch
type (attilla) :: branch(3)
end type

type (immabranch) :: branches

integer :: i

print*, "entering case 1"
do i=1,3
call z_onebythree_print(branches%branch(1)%atdisp(i)%zvec)
end do

print*, "exiting case 1 OK"
print*, " "
print*, "entering case 2"

do i=1,3
zvec = branches%branch(1)%atdisp(i)%zvec
call z_onebythree_print( zvec )
end do
print*, "exiting case 2 OK"

contains

subroutine z_onebythree_print(zvec)
complex(kind=8), intent(in) :: zvec(3)
character(len=1) :: xchar,ychar,zchar

print*, "made it into sub"

end subroutine z_onebythree_print
end program repro

--- end file ---

output
rwgreen-mac01:63141 rwgreen$ ifort -o repro -g -traceback repro.f90
rwgreen-mac01:63141 rwgreen$ ./repro
entering case 1
made it into sub
made it into sub
made it into sub
exiting case 1 OK

entering case 2
made it into sub
made it into sub
made it into sub

Thank you for this suggestion! I adjusted this code so that it was more like my datatypes (with allocatable arrays and whatnot), and I was unable to reproduce the error as well (even with giant branch and atdisp arrays). There must be something funky in my code. I'm going to take another look.

Thanks for your helpful comments.

Sincerely,

Demian

Re: Weird Segmentation Fault

riccardi — Sun, 25 Jan 2009 04:06:59 GMT

Hello again,

I have a simple code (posted below) that reproduces the problem. There are two types, seg and noseg: type seg has two entries (zvec(3) and vec(3)) while noseg has only zvec(3). The two subroutines (nosegfault and segfault differ only in the data type used). Apparantly, having the vec(3) but not using it causes the segfault, and I don't understand why. I am using v10.I also compiled this code with gfortran (version 4.2) and there is no seg fault. Thank you in advance for any insights!

Sincerely,

Demian

program repro

implicit none

type :: seg

complex(kind=8) :: zvec(3)

real(kind=8) :: vec(3)

end type seg

type :: noseg

complex(kind=8) :: zvec(3)

end type noseg

print *, "run with type noseg"

call nosegfault()

print *, "run with type seg"

call segfault()

contains

subroutine segfault()

type(seg), allocatable :: wide(:)

complex (kind=8),allocatable :: long(:)

complex (kind=8) :: zvec(3)

real(kind = 8) :: rval, ival

integer :: i,j, nlength_wide,nlength_long

nlength_wide = 92

nlength_long = nlength_wide * 3

allocate(wide(nlength_wide), stat=i)

allocate(long(nlength_long), stat=i)

do i = 1, nlength_long

long(i) = cmplx(0.0d0,0.0d0,kind=8)

end do

j = 1

do i = 1, nlength_wide

wide(i)%zvec(1) = long(j)

wide(i)%zvec(2) = long(j+1)

wide(i)%zvec(3) = long(j+2)

j = j + 3

end do

do i=1,nlength_wide

call z_onebythree_print(wide(i)%zvec)

end do

end subroutine

subroutine nosegfault()

type(noseg), allocatable :: wide(:)

complex (kind=8),allocatable :: long(:)

complex (kind=8) :: zvec(3)

real(kind = 8) :: rval, ival

integer :: i,j, nlength_wide,nlength_long

nlength_wide = 92

nlength_long = nlength_wide * 3

allocate(wide(nlength_wide), stat=i)

allocate(long(nlength_long), stat=i)

do i = 1, nlength_long

long(i) = cmplx(0.0d0,0.0d0,kind=8)

end do

j = 1

do i = 1, nlength_wide

wide(i)%zvec(1) = long(j)

wide(i)%zvec(2) = long(j+1)

wide(i)%zvec(3) = long(j+2)

j = j + 3

end do

do i=1,nlength_wide

call z_onebythree_print(wide(i)%zvec)

end do

end subroutine

subroutine z_onebythree_print(zvec)

complex(kind=8), intent(in) :: zvec(3)

character(len=1) :: xchar,ychar,zchar

real(kind=8) :: zero

zero = 0.0d0

xchar="+"

ychar="+"

zchar="+"

if(dimag(zvec(1)).lt. zero) xchar = "-"

if(dimag(zvec(2)).lt. zero) ychar = "-"

if(dimag(zvec(3)).lt. zero) zchar = "-"

print '(F10.4,a1,F6.4,a1,F10.4,a1,F6.4,a1,F10.4,a1,F6.4,a1)',&

dble(zvec(1)),xchar,abs(dimag(zvec(1))), "i", &

dble(zvec(2)),ychar,abs(dimag(zvec(2))), "i", &

dble(zvec(3)),zchar,abs(dimag(zvec(3))), "i"

end subroutine

end program repro

Re: Weird Segmentation Fault

Ron_Green — Mon, 26 Jan 2009 20:56:13 GMT

Strange, I used several 10.0 compilers, including a really old version 10.0.012. No seg fault.

Are you sure you tried compiling with -heap-arrays? And what is the output of:

ulimit -a

(the value for your stack ?)

output:

$ ifort -o repronew repronew.f90
[rwgreen@spd20 rwgreen]$ ./repronew
run with type noseg
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
run with type seg
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
0.0000+0.0000i 0.0000+0.0000i 0.0000+0.0000i
[rwgreen@spd20 rwgreen]$

Re: Weird Segmentation Fault

riccardi — Mon, 26 Jan 2009 23:04:20 GMT

Thank you for trying. I'm glad to see that it should work, but this is indeed weird. I did try -heap-arrays, and my stack size is65532kbytes. I have a feeling that it may be something unique to my machine. I tried it with version 8.1 on an older linux server running red hat 9 and it worked fine. As soon as my admin comes back from a trip, I'll see if she can help.

Demian

Re: Weird Segmentation Fault

Ron_Green — Tue, 27 Jan 2009 00:11:41 GMT

a few last parting thoughts:

If you use a batch system like PBS or LSF to submit jobs, be aware that under some batch subsystem your user environment may or may not be inherited by the child processes spawned on the remote nodes. Check into this (submit a batch job that simply returns the results of 'env'). This includes the stacksize.

Since you did mention using 10.0, check the ReleaseNotes in your "doc" subdirectory where the compiler is installed. This will have a list of the supported Linux distributions and releases. 10.0 is a little old, and there have been a lot of linux releases since 10.0 was released. I would worry about new linux releases running this older 10.0 compiler. If you tell me your OS distro and release ( OpenSUSE 11.0 for example, or Fedora Core 10) I could try this again with this distro and compiler. Or ask your admin to install the latest 11.0 compiler.

good hunting!

ron