Hello,

I am running a Model which I have sent in this link ( https://drive.google.com/file/d/1QLXutSW0mCOFMH1hfrhQzpOEgD8vamQy/view ). When I run my model (./ibis), I have the following error:

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x7fc13c55c32a
#1  0x7fc13c55b503
#2  0x7fc13bbd8fcf
#3  0x56089be188ff
#4  0x56089be2471d
#5  0x56089be25b53
#6  0x7fc13bbbbb96
#7  0x56089bdd3859
#8  0xffffffffffffffff
Segmentation fault (core dumped)

Could anybody help me to fix this problem?

I would appreciate your help.

That is a very general question you are posting. Invalid memory references can occur for a wide variety of reasons and it is not easy to find the root cause. However, a few things come to mind:

These techniques are simple to apply. What is much harder is to analyse the results and come up with the corrections your code needs.

Dear Arjen Markus,

Firstly, I have changed the runtime from 3600 seconds to  86400, and also I have used gfortran in Linux, but I have had the same problem. I installed Valgrind, but I do not know how to use it to solve my problem.

Best regards,

Negar, I attempted to download the file from the link that you gave, and found that the file was over a gigabyte in size ! At that point, I gave up because if I started debugging a program with source files of that size, I would probably need a few more lifetimes than I have to complete the task.

Arjen gave you some good suggestions. Unfortunately, when you compile a program with checks and debug output enabled, it will run more slowly than otherwise. If the access violation is caused by an array subscript bounds error, uninitialized subscript value, unallocated array, etc., even if you succeed in tracking down the error, fixing it will require intimate knowledge of the program being debugged.

You should think of contacting the authors of IBIS or an IBIS users' forum.

I do not think a change in runtime will help you with perse, but then I do not know the application.

Basic use of valgrind is rather simple. If your program is invoked as "./ibis" on the command-line, then type instead:

valgrind ./ibis

It will print its report on the console, so you will probably want to redirect it to a file for careful inspection.

I have the following reports, and I haven't understood what is the problem.

[NOTE: Negar contacted me by Private Message for help with this. She provided a link to a compressed archive, 690 MB long, containing the source and data files. Readers, please note that this thread is about troubleshooting input data and array size mismatches with a large Fortran program (IBIS) and that she is using Gfortran, not Intel Fortran.]

Negar, here is some advice for your consideration, before I show you what went wrong.

I built the program from your sources on Windows 10/Cygwin 64 using Gfortran 10.2 with the command

gfortran -Iinc -fallow-argument-mismatch -ffixed-line-length-0 -g -C src/*.f -lnetcdff -lnetcdf -o gibis

Note the two options that I used for debugging: -g, which puts debug information into the EXE/a.out, and -C, which adds code to check subscripts.

When I ran the resulting program, ibis.exe, the output was:

S:\Negar>gibis
 ****************************************
 * IBIS: Integrated BIosphere Simulator *
 * Version 2.6b3                        *
 * March 2002                           *
 ****************************************
 length of this simulation (years)   :       19
 year to begin using anomalies       :     9999
 model lon, lat resolution (degrees) :     0.02    0.02
 model domain (nlon x nlat)          : 617 by 534
 number of iterations per day        :       24
 last year run in this sequence      :     2019
 RD_PARAM: All data read in from parameter files successfully.
 ERROR in subroutine readit
 number of land points in input/surta.nc
 does not match number of land points in compar.h
 in surta =       18946  in compar.h =           3
STOP 1

Here is how the access violation occurred: Line 4063 of IO.F contains

            garea(nlpoints) = yres * 111400.0 * xres * 111400.0 * cos(xlat)

The array GAREA is declared GAREA(3), yet the data is such that NLPOINTS can reach values in the thousands.

Here is what you have to do: in file COMPAR.H, there is a parameter, NPOI, currently given the value 3. You have to replace that '3' with a value that is large enough. How much? That is something that you will have to work out yourself, using the IBIS documentation + the source and include files, or with the help of an experienced IBIS user. I cannot tell you what to use because I neither use IBIS, nor do I know how to read the voluminous input data files.

Note that the IBIS source code handles this matter of array sizing in an outmoded way. The modern way is to read enough of the input data to ascertain/calculate the required array sizes, and then ALLOCATE those arrays to the exact size required -- like buying shoes that fit, rather than the biggest size that any human would ever require.

The part of the IBIS code that did the checking is fine, but the code may well have crashed with an access violation or other error earlier, because the comparison of the array upper bound to the number of points is performed after all the points have been read in. An array violation occurs after only 3 points have been read in, but whether this gets detected depends quite a bit on the compiler and compiler options used.

Dear @negar

I am glad that @mecej4 showed you how to solve the problem. You certainly hit the correct forum.

@mecej4 suggested the following:

The modern way is to read enough of the input data to ascertain/calculate the required array sizes, and then ALLOCATE those arrays to the exact size required -- like buying shoes that fit, rather than the biggest size that any human would ever require.

An alternative way that I use, because I get lots of huge input files from all over the world is to create a simple txt file and store it with the program. In it you can place the size of arrays you need each time and then allocate on starting the program.  It helps if you have a lot of samples to run and you want to be as quick as possible.

Just a thought - a simple sample:

Hello again,

Build in Debug mode with all compile time .AND. runtime checks enabled.

Correct all compile time errors and warnings.

Then run to see if runtime errors occur. Note, not all runtime errors can be detected.

If this exposes fixable errors, then fix them, compile as stated above and run again.

When (if) you still have unresolved NaN's then post back here.

Because the NaN errors appear as you grow your data, this may be a case of accessing array(s) out of bounds. The runtime checks should catch most of these (but not all instances of these).

To help locate the point of error, start at the point of the NaN printout and then work backwards in your code inserting test for NaN on the offending variable(s). At some point you will discover where the NaN is introduced. Then look around there for cause.

Jim Dempsey

Sorry, compile time diagnostics and warnings

/warn:all
/check:all

Also, it is very helpful to assure IMPLICIT NONE is used in subroutines and functions such that typographical errors (and mis-typings) are detected.

Jim Dempsey

A large number where a small one is expected is an indication that something is wrong.

Follow the same advice as for the NaN...

Starting at the point where you know a value is incorrect, go backwards in your code inserting test to locate the point in the code where the number deviates from the expected result. Then determine the cause of the deviation. Hint: I find it easy to add a helper subroutine such as:

subroutine DebugThis()
print *,"bug" ! Break here
end subroutine DebugThis

Then in your code

IF(YourNumberThatBlowsUp > 10) call DebugThis()

Then you insert that further back into your code to locate the point of deviation.

Of course you would have to modify the test condition as  you may need to test the constituents.

Note, when you are at the break point, use the Call Stack window to set the focus at the higher stack levels (such that you can examine the variables in the scope of the caller). You may need to go up more than one call level to locate the next source(s) of generation of the error.

Also, you could use the Fortran Preprocessor and then pass in as arguments __LINE__, __FILE__

And print that out (and then STOP)

Note, in the debugger, you can (at STOP) use the Debugger "Set Next Statement" to position at the END SUBROUTINE statement such that you can return if need be for testing.

Jim Dempsey

Community support is provided during standard business hours (Monday to Friday 7AM - 5PM PST). Other contact methods are available here .

Intel does not verify all solutions, including but not limited to any file transfers that may appear in this community. Accordingly, Intel disclaims all express and implied warranties, including without limitation, the implied warranties of merchantability, fitness for a particular purpose, and non-infringement, as well as any warranty arising from course of performance, course of dealing, or usage in trade.

For more complete information about compiler optimizations, see our Optimization Notice .