Respected sir,
i have run the wrf and getting error segmentation fault invalid memory reference but i have checked and we have sufficient memory. So kindly help me out here we can not pinpoint the exact problem.

Regards
Pramod
IESD BHU

Pramod Yadava <pkindia002@gmail.com> schrieb:
> Respected sir,
> i have run the wrf and getting error segmentation fault invalid memory reference but i have checked and we have sufficient memory. So kindly help me out here we can not pinpoint the exact problem.

Depends on your compiler.

If you use gfortran, compile with the options "-g -fcheck=all" and see
what errors you get. Other compilers have similar options.

This may already pinpoint the problem. If not, there are a few
other things to try.

On Saturday, September 17, 2022 at 6:51:08 PM UTC+10, Pramod Yadava wrote:
> Respected sir,
> i have run the wrf and getting error segmentation fault invalid memory reference but i have checked and we have sufficient memory. So kindly help me out here we can not pinpoint the exact problem.
..
You need to provide the code.
..
Your request is like "My car won't start. What's wrong with it?"

On 9/17/2022 3:51 AM, Pramod Yadava wrote:
> Respected sir,
> i have run the wrf and getting error segmentation fault invalid memory reference but i have checked and we have sufficient memory. So kindly help me out here we can not pinpoint the exact problem.
>
>
> Regards
> Pramod
> IESD BHU

You need to run the code through a debugger and see where the segfault
is being generated.

One of the most common issues is overrunning a local array:

double precision x (10)
....
x (11) = 11.0

That will get you almost any time.

Lynn

Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
> On 9/17/2022 3:51 AM, Pramod Yadava wrote:
>> Respected sir,
>> i have run the wrf and getting error segmentation fault invalid memory reference but i have checked and we have sufficient memory. So kindly help me out here we can not pinpoint the exact problem.
>>
>>
>> Regards
>> Pramod
>> IESD BHU
>
> You need to run the code through a debugger and see where the segfault
> is being generated.
>
> One of the most common issues is overrunning a local array:
>
> double precision x (10)
> ...
> x (11) = 11.0
>
> That will get you almost any time.

$ cat double.f90
program memain
real, dimension(10) :: a
do i=1,11
a(i) = 0.0
end do
end program memain
$ gfortran double.f90
double.f90:4:7:

3 | do i=1,11
| 2
4 | a(i) = 0.0
| 1
Warning: Array reference at (1) out of bounds (11 > 10) in loop beginning at (2)

(Well, it works for statically declared arrays, anyway).

On Monday, September 19, 2022 at 4:07:20 PM UTC+10, Thomas Koenig wrote:
> Lynn McGuire <lynnmc...@gmail.com> schrieb:
> > On 9/17/2022 3:51 AM, Pramod Yadava wrote:
> >> Respected sir,
> >> i have run the wrf and getting error segmentation fault invalid memory reference but i have checked and we have sufficient memory. So kindly help me out here we can not pinpoint the exact problem.
> >>
> >>
> >> Regards
> >> Pramod
> >> IESD BHU
> >
> > You need to run the code through a debugger and see where the segfault
> > is being generated.
> >
> > One of the most common issues is overrunning a local array:
> >
> > double precision x (10)
> > ...
> > x (11) = 11.0
> >
> > That will get you almost any time.
> $ cat double.f90
> program memain
> real, dimension(10) :: a
> do i=1,11
> a(i) = 0.0
> end do
> end program memain
> $ gfortran double.f90
> double.f90:4:7:
>
> 3 | do i=1,11
> | 2
> 4 | a(i) = 0.0
> | 1
> Warning: Array reference at (1) out of bounds (11 > 10) in loop beginning at (2)
>
> (Well, it works for statically declared arrays, anyway).
..
This is easy enough to do at compile time, as the violation occurs
in the same procedure as the declaration with explicit bounds.
It becomes more difficult when the declaration is in another
procedure. The diagnosis in such cases is then typically required at
run time (and, in particular, when the bounds are dynamically generated).

On 9/19/22 1:49 AM, Robin Vowels wrote:
> On Monday, September 19, 2022 at 4:07:20 PM UTC+10, Thomas Koenig wrote:
>> Lynn McGuire <lynnmc...@gmail.com> schrieb:
>>> On 9/17/2022 3:51 AM, Pramod Yadava wrote:
>>>> Respected sir,
>>>> i have run the wrf and getting error segmentation fault invalid memory reference but i have checked and we have sufficient memory. So kindly help me out here we can not pinpoint the exact problem.
>>>>
>>>>
>>>> Regards
>>>> Pramod
>>>> IESD BHU
>>>
>>> You need to run the code through a debugger and see where the segfault
>>> is being generated.
>>>
>>> One of the most common issues is overrunning a local array:
>>>
>>> double precision x (10)
>>> ...
>>> x (11) = 11.0
>>>
>>> That will get you almost any time.
>> $ cat double.f90
>> program memain
>> real, dimension(10) :: a
>> do i=1,11
>> a(i) = 0.0
>> end do
>> end program memain
>> $ gfortran double.f90
>> double.f90:4:7:
>>
>> 3 | do i=1,11
>> | 2
>> 4 | a(i) = 0.0
>> | 1
>> Warning: Array reference at (1) out of bounds (11 > 10) in loop beginning at (2)
>>
>> (Well, it works for statically declared arrays, anyway).
> .
> This is easy enough to do at compile time, as the violation occurs
> in the same procedure as the declaration with explicit bounds.
> It becomes more difficult when the declaration is in another
> procedure. The diagnosis in such cases is then typically required at
> run time (and, in particular, when the bounds are dynamically generated).

This is why it might be useful to see why the original code, when
compiled with bounds checking, did not detect the array index overrun.
What quirky combination of situations and circumstances caused both the
compile time and the run time detection to fail? This information would
help the compiler writers to tighten up their diagnostics and also
normal programmers from falling into that trap in the future.

$.02 -Ron Shepard

On Monday, September 19, 2022 at 7:05:26 AM UTC-7, Ron Shepard wrote:

(snip)

> This is why it might be useful to see why the original code, when
> compiled with bounds checking, did not detect the array index overrun.
> What quirky combination of situations and circumstances caused both the
> compile time and the run time detection to fail? This information would
> help the compiler writers to tighten up their diagnostics and also
> normal programmers from falling into that trap in the future.

Yes.

There are some that are known to be harder to detect, though
not obvious enough for us to guess.

Ron Shepard <nospam@nowhere.org> schrieb:
> On 9/19/22 1:49 AM, Robin Vowels wrote:
>> On Monday, September 19, 2022 at 4:07:20 PM UTC+10, Thomas Koenig wrote:
>>> Lynn McGuire <lynnmc...@gmail.com> schrieb:
>>>> On 9/17/2022 3:51 AM, Pramod Yadava wrote:
>>>>> Respected sir,
>>>>> i have run the wrf and getting error segmentation fault invalid memory reference but i have checked and we have sufficient memory. So kindly help me out here we can not pinpoint the exact problem.
>>>>>
>>>>>
>>>>> Regards
>>>>> Pramod
>>>>> IESD BHU
>>>>
>>>> You need to run the code through a debugger and see where the segfault
>>>> is being generated.
>>>>
>>>> One of the most common issues is overrunning a local array:
>>>>
>>>> double precision x (10)
>>>> ...
>>>> x (11) = 11.0
>>>>
>>>> That will get you almost any time.
>>> $ cat double.f90
>>> program memain
>>> real, dimension(10) :: a
>>> do i=1,11
>>> a(i) = 0.0
>>> end do
>>> end program memain
>>> $ gfortran double.f90
>>> double.f90:4:7:
>>>
>>> 3 | do i=1,11
>>> | 2
>>> 4 | a(i) = 0.0
>>> | 1
>>> Warning: Array reference at (1) out of bounds (11 > 10) in loop beginning at (2)
>>>
>>> (Well, it works for statically declared arrays, anyway).
>> .
>> This is easy enough to do at compile time, as the violation occurs
>> in the same procedure as the declaration with explicit bounds.
>> It becomes more difficult when the declaration is in another
>> procedure. The diagnosis in such cases is then typically required at
>> run time (and, in particular, when the bounds are dynamically generated).
>
> This is why it might be useful to see why the original code, when
> compiled with bounds checking, did not detect the array index overrun.
> What quirky combination of situations and circumstances caused both the
> compile time and the run time detection to fail? This information would
> help the compiler writers to tighten up their diagnostics and also
> normal programmers from falling into that trap in the future.

There are several cases that come to mind that could easily
create such an error. A few examples:

real, dimension(10) :: a
call foo(a)
call bar(a)
call baz(a,11)
...

subroutine foo(a)
real, dimension(*) :: a
a(11) = 42.

SUBROUTINE BAR
REAL A(1) ! Old form of a(*), bounds checking off
A(11) = 42

subroutine baz(a,n)
integer :: n
real, dimension(n) :: a
a(n) = 42

Very difficult to detect, even at run-time. That is one reason
why assumed-shape arrays are so powerful.

On 9/20/22 12:20 AM, Thomas Koenig wrote:
> There are several cases that come to mind that could easily
> create such an error. A few examples:
>
> real, dimension(10) :: a
> call foo(a)
> call bar(a)
> call baz(a,11)
> ...
>
> subroutine foo(a)
> real, dimension(*) :: a
> a(11) = 42.
>
> SUBROUTINE BAR
> REAL A(1) ! Old form of a(*), bounds checking off
> A(11) = 42
>
> subroutine baz(a,n)
> integer :: n
> real, dimension(n) :: a
> a(n) = 42

The OP said that the array was dimensioned 1:10, and he referenced
element 0 out of bounds. I would think that would normally be a case
that the compiler could catch.

$.02 -Ron Shepard

On Tuesday, September 20, 2022 at 12:08:33 AM UTC-7, Ron Shepard wrote:

(snip)

> The OP said that the array was dimensioned 1:10, and he referenced
> element 0 out of bounds. I would think that would normally be a case
> that the compiler could catch.

It does say that, but it doesn't say that the reference is in the same
subroutine.

First of all, with most systems you need to specify bounds check
on every compilation, if separate compilation is used.
And as noted above, some are more difficult to detect.

Though I have noted compilers that will detect the second (BAR)
case, even with (run-time) bounds check turned off.

On Tuesday, September 20, 2022 at 3:20:15 PM UTC+10, Thomas Koenig wrote:
> Ron Shepard <nos...@nowhere.org> schrieb:
> > On 9/19/22 1:49 AM, Robin Vowels wrote:
> >> On Monday, September 19, 2022 at 4:07:20 PM UTC+10, Thomas Koenig wrote:
> >>> Lynn McGuire <lynnmc...@gmail.com> schrieb:
> >>>> On 9/17/2022 3:51 AM, Pramod Yadava wrote:
> >>>>> Respected sir,
> >>>>> i have run the wrf and getting error segmentation fault invalid memory reference but i have checked and we have sufficient memory. So kindly help me out here we can not pinpoint the exact problem.
> >>>>>
> >>>>>
> >>>>> Regards
> >>>>> Pramod
> >>>>> IESD BHU
> >>>>
> >>>> You need to run the code through a debugger and see where the segfault
> >>>> is being generated.
> >>>>
> >>>> One of the most common issues is overrunning a local array:
> >>>>
> >>>> double precision x (10)
> >>>> ...
> >>>> x (11) = 11.0
> >>>>
> >>>> That will get you almost any time.
> >>> $ cat double.f90
> >>> program memain
> >>> real, dimension(10) :: a
> >>> do i=1,11
> >>> a(i) = 0.0
> >>> end do
> >>> end program memain
> >>> $ gfortran double.f90
> >>> double.f90:4:7:
> >>>
> >>> 3 | do i=1,11
> >>> | 2
> >>> 4 | a(i) = 0.0
> >>> | 1
> >>> Warning: Array reference at (1) out of bounds (11 > 10) in loop beginning at (2)
> >>>
> >>> (Well, it works for statically declared arrays, anyway).
> >> .
> >> This is easy enough to do at compile time, as the violation occurs
> >> in the same procedure as the declaration with explicit bounds.
> >> It becomes more difficult when the declaration is in another
> >> procedure. The diagnosis in such cases is then typically required at
> >> run time (and, in particular, when the bounds are dynamically generated).
> >
> > This is why it might be useful to see why the original code, when
> > compiled with bounds checking, did not detect the array index overrun.
> > What quirky combination of situations and circumstances caused both the
> > compile time and the run time detection to fail? This information would
> > help the compiler writers to tighten up their diagnostics and also
> > normal programmers from falling into that trap in the future.
> There are several cases that come to mind that could easily
> create such an error. A few examples:
>
> real, dimension(10) :: a
> call foo(a)
> call bar(a)
> call baz(a,11)
> ...
>
> subroutine foo(a)
> real, dimension(*) :: a
> a(11) = 42.
>
> SUBROUTINE BAR
> REAL A(1) ! Old form of a(*), bounds checking off
> A(11) = 42
>
> subroutine baz(a,n)
> integer :: n
> real, dimension(n) :: a
> a(n) = 42
>
> Very difficult to detect, even at run-time. That is one reason
> why assumed-shape arrays are so powerful.
..
It is usually unnecessary to pass in the bound of an array.
It is important to create an interface block for each procedure
(a quick and effective way to do that is to use CONTAINS).
Old/obsolete forms of the language should not be intermixed
with modern safe forms.
Obsolete and error-prone forms of the language should not be used.

(snip)

> Obsolete and error-prone forms of the language should not be used.

Some of us run old obsolete programs, and don't feel like rewriting them.

Last year, I had IBM's ECAP running. It seems to trace to Fortran II days,
though was later partly updated to Fortran IV, but with many older
constructs still there.

Among others, it has a feature that I have never seen anywhere else.
It seems that you can:

CALL LINK(program)

and it will load another program replacing the current one, but keeping
the variables in COMMON. And, interestingly, it is not a string constant.

To make that work, I write all the COMMON blocks out to a disk file,
and read them back in later. Funny features that used to be there.

On Tue, 20 Sep 2022 14:26:20 -0700 (PDT), gah4 <gah4@u.washington.edu> wrote:
: : (snip)
: :> Obsolete and error-prone forms of the language should not be used.
: : Some of us run old obsolete programs, and don't feel like rewriting them.
: : Last year, I had IBM's ECAP running. It seems to trace to Fortran II days,
: though was later partly updated to Fortran IV, but with many older
: constructs still there.
: : Among others, it has a feature that I have never seen anywhere else.
: It seems that you can:
: : CALL LINK(program)
: : and it will load another program replacing the current one, but keeping
: the variables in COMMON. And, interestingly, it is not a string constant.
: : To make that work, I write all the COMMON blocks out to a disk file,
: and read them back in later. Funny features that used to be there.
: Boy, does that bring back memories! I learned programming (Fortran II) on
an IBM 1620 back in the early 60's. Later, I had to get ECAP running on
a 1620 model 2 which used FORTRAN IID.

You have the use of CALL LINK correct. It allowed programs which needed
more core than was available to be broken up into smaller pieces which
this statement could link together.

On Wednesday, September 21, 2022 at 7:26:22 AM UTC+10, gah4 wrote:
> (snip)
> > Obsolete and error-prone forms of the language should not be used.
..
> Some of us run old obsolete programs, and don't feel like rewriting them.
..
I was referring to the example given (which you omitted).
No-one suggested anything like rewriting old programs.
..
> Last year, I had IBM's ECAP running. It seems to trace to Fortran II days,
> though was later partly updated to Fortran IV, but with many older
> constructs still there.

gah4 <gah4@u.washington.edu> schrieb:
>
> (snip)
>
>> Obsolete and error-prone forms of the language should not be used.
>
> Some of us run old obsolete programs, and don't feel like rewriting them.
>
> Last year, I had IBM's ECAP running. It seems to trace to Fortran II days,
> though was later partly updated to Fortran IV, but with many older
> constructs still there.
>
> Among others, it has a feature that I have never seen anywhere else.
> It seems that you can:
>
> CALL LINK(program)
>
> and it will load another program replacing the current one, but keeping
> the variables in COMMON. And, interestingly, it is not a string constant.
>
> To make that work, I write all the COMMON blocks out to a disk file,
> and read them back in later. Funny features that used to be there.

The old systems had overlays, yes. I read the documentation at
the time I was working on mainframe systems, but I never needed
to use them.

What you can do today is the following: If you have two overlaid
programs which share COMMON data, just make the two PROGRAMs into
SUBROUTINEs and call them in turn.

There might be a problem with subroutines having the same name
in both programs, with different meanings. In that case, put
them into separate modules and make everything private except
for the called main program.

So, turn

PROGRAM P1
COMMON /COM/ ...
END PROGRAM P1

PROGRAM P2
COMMON /COM/ ...
END PROGRAM P2

into (keeping to fixed source here :-)

MODULE MY_COM
! Declare variables
COMMON /COM /...
END MODULE MY_COM

MODULE MY_P1
USE MY_COM
PRIVATE
PUBLIC :: P1
CONTAINS
SUBROUTINE P1
...
END SUBROUTINE P1
END MODULE MY_P1

MODULE MY_P2
USE MY_COM
PRIVATE
PUBLIC :: P2
CONTAINS
SUBROUTINE P2
...
END SUBROUTINE P2
END MODULE MY_P2

PROGRAMME MAIN
USE MY_P1, MY_P2
CALL P1
CALL P2

....

On Wednesday, September 21, 2022 at 5:43:50 AM UTC-7, Thomas Koenig wrote:
> gah4 <ga...@u.washington.edu> schrieb:

(snip)

> > Last year, I had IBM's ECAP running. It seems to trace to Fortran II days,
> > though was later partly updated to Fortran IV, but with many older
> > constructs still there.
> > Among others, it has a feature that I have never seen anywhere else.
> > It seems that you can:
> > CALL LINK(program)
> > and it will load another program replacing the current one, but keeping
> > the variables in COMMON. And, interestingly, it is not a string constant.
> > To make that work, I write all the COMMON blocks out to a disk file,
> > and read them back in later. Funny features that used to be there.

> The old systems had overlays, yes. I read the documentation at
> the time I was working on mainframe systems, but I never needed
> to use them.
> What you can do today is the following: If you have two overlaid
> programs which share COMMON data, just make the two PROGRAMs into
> SUBROUTINEs and call them in turn.

There is also an ECAP for the PDP-10, which does that.
It also uses many DEC specific features that are not in any standard.

The way it actually works, is that there is a main program that reads
in all the input data cards, one of which tells it to do DC, AC, or
transient analysis. It then LINKs to the appropriate program,
for that analysis. When done, that one LINKs back to main.

It does get more interesting, though. You can do a follow-on,
without entering the whole thing again. Maybe change one
parameter, and then try again.

In any case, yes, I could make them into subroutines, and then
when one returns, it goes to the right place.

In some cases, it might be more complicated. Instead of return,
it might link to different routines, that link to other different routines.
In that case, it would be necessary to pass back an indication of
where to go next.

It seems that this is before the overlays as I have always known them,
which work on subroutine calls, and overlay only part of the program.
I have known those overlays on many different systems.