segmentation fault

[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]

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

[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]

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]

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]

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?

[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]

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)

[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]

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.

[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.

[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.