segmentation fault

Discussion on computers, ROMS installation and compiling

Moderators: arango, robertson

Post Reply
Message
Author
leonjld
Posts: 51
Joined: Fri Feb 27, 2004 6:30 pm
Location: NOAA/NESDIS/STAR

segmentation fault

#1 Unread post by leonjld »

HI, I downloaded roms2.2c and sucessfully compiled it on a Sun system using f95. I didn't modify any files and tried to run the default settings. However when I execute the program it shows the following:

% ./oceanG < ocean_upw.in
Process Information:

Thread # 0 (pid= 16782) is active.

Model Input Parameters: ROMS/TOMS version 2.2
Tuesday - February 6, 2007 - 12:07:31 PM
-----------------------------------------------------------------------------
Segmentation fault (core dumped)

Am I doing someting wrong? (I turned on the debug mode)

leonjld
Posts: 51
Joined: Fri Feb 27, 2004 6:30 pm
Location: NOAA/NESDIS/STAR

#2 Unread post by leonjld »

if I turn off the debug switch, then when I use 'make' I have errors as following:

"pre_step3d.f90", Line = 174, Column = 1: INTERNAL: Interrupt: Segmentation Fault
make: *** [pre_step3d.o] Error 2

Is it a machine issue or else? I'm using Solaris SPARC

User avatar
kate
Posts: 4091
Joined: Wed Jul 02, 2003 5:29 pm
Location: CFOS/UAF, USA

#3 Unread post by kate »

That's a compiler bug, or optimizer bug to be precise. I'm using the Sun complier on Linux and have to use -O2 rather than -O3. You might try that, but I don't know why you're getting the error in the first post unless something in your limits is set impossibly low. Do you have the option of trying gfortran or some other compiler or some other computer?

leonjld
Posts: 51
Joined: Fri Feb 27, 2004 6:30 pm
Location: NOAA/NESDIS/STAR

#4 Unread post by leonjld »

kate wrote:That's a compiler bug, or optimizer bug to be precise. I'm using the Sun complier on Linux and have to use -O2 rather than -O3. You might try that, but I don't know why you're getting the error in the first post unless something in your limits is set impossibly low. Do you have the option of trying gfortran or some other compiler or some other computer?
Thanks for your replay,Kate. It seems you are right that the problem lies in the optimizer switch -O3. I had the same error using -O2, but succeeded in compiling without using any of -O2 or -O3. However I ran into the same situation as in the first post. I wonder if the 'limit' you referred to is this:

% limit
cputime unlimited
filesize unlimited
datasize unlimited
stacksize 8192 kbytes
coredumpsize unlimited
vmemoryuse unlimited
descriptors 256

I didn't change anything in the source codes. But I guess even I succeed in running it, without -O2 or -O3 the running process can take years.

Unfortunately I don't have other kind of computer that I can use. However I was using the Roms_Agrif from IRD which runs great on my machine. I am just trying to use this Rutgers ROMs.

gerardo
Posts: 12
Joined: Wed Sep 27, 2006 7:23 pm
Location: SGI

#5 Unread post by gerardo »

leonjld wrote: Thanks for your replay,Kate. It seems you are right that the problem lies in the optimizer switch -O3. I had the same error using -O2, but succeeded in compiling without using any of -O2 or -O3. However I ran into the same situation as in the first post. I wonder if the 'limit' you referred to is this:

% limit
cputime unlimited
filesize unlimited
datasize unlimited
stacksize 8192 kbytes
...
The 8MB stacksize limit is most likely the cause of the segmentation fault. You
can change it by executing 'limit stacksize unlimited'. When you execute
'limit' again you will see a stacksize of 'unlimited' or whichever value your
system administrator set as the hard limit for users.

A 'segmentation fault' means the program tried to access a memory address
that it is not allowed to access. For a defective program, this usually means
a bad pointer or out-of-bounds indices. If the program isn't defective, it will
usually mean it ran out of some memory resource, most commonly space
in the stack (where local variables and arrays are allocated).

Saludos,
--
Gerardo

leonjld
Posts: 51
Joined: Fri Feb 27, 2004 6:30 pm
Location: NOAA/NESDIS/STAR

#6 Unread post by leonjld »

Thanks Gerardo. I tried but still not work. In debug compiling mode I get:

ild: (Performing full relink) internal free space in output file exhausted (dynamic string table)

Then when I ran it, still the same segmentation fault.

The limits are now:

% limit
cputime unlimited
filesize unlimited
datasize unlimited
stacksize unlimited
coredumpsize unlimited
vmemoryuse unlimited
descriptors 65536

I guess the machine itself has inadequate memory?

User avatar
m.hadfield
Posts: 521
Joined: Tue Jul 01, 2003 4:12 am
Location: NIWA

#7 Unread post by m.hadfield »

This is a serial run with just one thread, no?

Try increasing the number of threads: NI =1 and NJ=8 might be a good starting point. This reduces the amount of space required for temporary storage. On x86 processors it normally makes the model run faster, too.

leonjld
Posts: 51
Joined: Fri Feb 27, 2004 6:30 pm
Location: NOAA/NESDIS/STAR

#8 Unread post by leonjld »

m.hadfield wrote:This is a serial run with just one thread, no?

Try increasing the number of threads: NI =1 and NJ=8 might be a good starting point. This reduces the amount of space required for temporary storage. On x86 processors it normally makes the model run faster, too.
Thank you but I'm not sure how to do this. Can you inform me where to modify NI and NJ? Is it in the input file as 'NTileI' and 'NTileJ'? It is a serial run, and we don't have parallel computing capabilities.

The segmentation fault is generated even when I didn't put any input file:

% ./oceanG
Process Information:

Thread # 0 (pid= 5834) is active.

Model Input Parameters: ROMS/TOMS version 2.2
Wednesday - February 7, 2007 - 3:47:59 PM
-----------------------------------------------------------------------------
Segmentation fault (core dumped)

User avatar
m.hadfield
Posts: 521
Joined: Tue Jul 01, 2003 4:12 am
Location: NIWA

#9 Unread post by m.hadfield »

Sorry, I meant NtileI and NtileJ.
The segmentation fault is generated even when I didn't put any input file
Hmm, not sure how to interpret this. It could be a completely different problem (after all, running the model without an input file is not recommended). But it does suggest that changing the tiling will make no difference, since the model crashes before it has read this info. Still give it a go.

Maybe your model run is just too big. Can you try again with a smaller one?

By the way, running in debug mode will probably increase your memory requirements and make a segmentation fault more likely. So try without it.

leonjld
Posts: 51
Joined: Fri Feb 27, 2004 6:30 pm
Location: NOAA/NESDIS/STAR

#10 Unread post by leonjld »

I tried it without debug model also. with -O2 or -O3, both will generate segmentation fault during the compilation of pre_step3d.f90:

f95 -c -u -U -O3 pre_step3d.f90
"pre_step3d.f90", Line = 174, Column = 1: INTERNAL: Interrupt: Segmentation Fault

The code is:


integer :: IstrR, IendR, JstrR, JendR, IstrU, JstrV
integer :: i, indx, is, itrc, j, k, ltrc
real(r8), parameter :: Gamma = 1.0_r8/6.0_r8
real(r8), parameter :: eps = 1.0E-16_r8
real(r8) :: cff, cff1, cff2, cff3, cff4
real(r8), dimension(Istr-3:Iend+3,0:N(ng)) :: CF
real(r8), dimension(Istr-3:Iend+3,0:N(ng)) :: DC
real(r8), dimension(Istr-3:Iend+3,0:N(ng)) :: FC <------ Line 174
real(r8), dimension(Istr-3:Iend+3,Jstr-3:Jend+3) :: FE
real(r8), dimension(Istr-3:Iend+3,Jstr-3:Jend+3) :: FX
real(r8), dimension(Istr-3:Iend+3,Jstr-3:Jend+3) :: curv
real(r8), dimension(Istr-3:Iend+3,Jstr-3:Jend+3) :: grad



Without -O2 or -O3, the oceanS can be generated successfully, but the result will be the same as oceanG.

I tried it on two work stations in the lab and both of them have the same errors.

User avatar
m.hadfield
Posts: 521
Joined: Tue Jul 01, 2003 4:12 am
Location: NIWA

#11 Unread post by m.hadfield »

During the compilation?! I didn't review the thread very carefully and I was responding to the message about the run-time segmentation fault. A segfault during compilation indicates a compiler bug, or *possibly* a broken environment.

The following certainly suggests a compiler/linker bug:
d: (Performing full relink) internal free space in output file exhausted (dynamic string table)
One must ask the question: even if it manages to compile, is the machine code it generates correct?

You're on Linux? Intel? Why not try a compiler that works? E.g., Intel Fortran, G95, Gfortran.

By the way, ROMS supports two different styles of argument passing, assumed-shape and explicit-shape, according to the ASSUMED_SHAPE macro, set in globaldefs.h. (We're on Rutgers ROMS, right.) This is to cope with compiler bugs and performance differences. You might try changing the setting.

User avatar
kate
Posts: 4091
Joined: Wed Jul 02, 2003 5:29 pm
Location: CFOS/UAF, USA

#12 Unread post by kate »

I second the advice to find another system/compiler to try this on. UPWELLING is small enough that you shouldn't be bumping up against any reasonable limits.

Post Reply