• Segmentation Fault error

    From Pramod Yadava@21:1/5 to All on Sat Sep 17 01:51:06 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Thomas Koenig@21:1/5 to Pramod Yadava on Sat Sep 17 08:55:53 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robin Vowels@21:1/5 to Pramod Yadava on Sat Sep 17 04:41:02 2022
    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?"

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lynn McGuire@21:1/5 to Pramod Yadava on Sat Sep 17 22:26:44 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Thomas Koenig@21:1/5 to Lynn McGuire on Mon Sep 19 06:07:17 2022
    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).

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robin Vowels@21:1/5 to Thomas Koenig on Sun Sep 18 23:49:34 2022
    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).

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ron Shepard@21:1/5 to Robin Vowels on Mon Sep 19 09:05:16 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to Ron Shepard on Mon Sep 19 09:38:16 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Thomas Koenig@21:1/5 to Ron Shepard on Tue Sep 20 05:20:12 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ron Shepard@21:1/5 to Thomas Koenig on Tue Sep 20 02:08:29 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to Ron Shepard on Tue Sep 20 02:02:45 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robin Vowels@21:1/5 to Thomas Koenig on Tue Sep 20 04:14:59 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to All on Tue Sep 20 14:26:20 2022
    (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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From George Schroeder@21:1/5 to gah4@u.washington.edu on Tue Sep 20 22:54:04 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robin Vowels@21:1/5 to All on Tue Sep 20 22:41:04 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Thomas Koenig@21:1/5 to gah4@u.washington.edu on Wed Sep 21 12:43:47 2022
    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

    ...

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to Thomas Koenig on Wed Sep 21 13:31:14 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)