0

I am trying to run a simple code to create arrays. This code was working before. However, now it has somehow stopped working and throws a runtime error. Here is the piece of code that causes the trouble.

      call PF33(thetamix,rhodhI,16)
      subroutine PF33(thetamix,rhodhI,N)
      implicit none

      integer*8 N, thetamix,rhodhI
      real*8 k1, k2,k4, k2x, k4x
      dimension k1(N), k2(N), k4(N), k2x(N), k4x(N), X(N)
      do i = 1, N/2
        k1(i) = (2 * pi / L) * (i - 1)
      enddo
      do i = N/2 + 2, N
        k1(i) = -((N - i + 1) * (2 * pi / L))
      enddo
      k1(N/2 + 1) = ((N/2) * (2 * pi / L))

      k2=k1*k1
      k2(N/2+1)=((N/2)*(2*pi/L))**2
      k4=k2*k2
      k4(N/2+1)=((N/2)*(2*pi/L))**4
      k2x=k2
      k4x=k4
    
      return
      end

N is a dummy attribute that is taken from the subroutine call. The second k1 loop is the line where I get the error. Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x7ffb858b877d in ???
#1  0x7ffb858b7993 in ???
#2  0x7ffb8544251f in ???
#3  0x55741fee21f5 in pf33_
    at /home/raghav/Desktop/SeaIce/FeapElement/Andrea-Feap/home/andrea/feap/ver84/user/PF33.f:123
#4  0x55741fed81d3 in uprhoha_as33_

What am I missing? Thanks in advance

R2197
  • 9
  • 4
  • 1
    A segmentation violation is often because the program tries writing to forbiden memory areas. Here it can be because `N` is greater than the actual size of the `k1` array. But without seeing the whole code it's difficult to say. – PierU Aug 09 '23 at 13:50
  • in addition to the comment from PierU: what is the value of N in case of the crash? – albert Aug 09 '23 at 13:58
  • Hey PierU, thanks for your answer. k1 array is initialised using N with dimension k1(N). This code was working before but somehow it has now stopped. So, I am not even sure if this k1 is the real issue. But the error message shows the corresponding line number. Could there is be any other thing to look at? – R2197 Aug 09 '23 at 13:58
  • How big is N? These are not dynamic arrays, so you might end up with a stack overflow. – lastchance Aug 09 '23 at 13:59
  • Hey @albert, it's for now 16. But I can change it. It doesn't matter at the moment. – R2197 Aug 09 '23 at 13:59
  • If `k1` is an argument of the routine, it can be dimensioned to any "fake" size, regardless the actual size in memory. We need to see more code: if possible the whole subroutine, and how `k1` is declared/allocated before the call of the routine. – PierU Aug 09 '23 at 14:00
  • When put in a subroutine I can't make that code crash unless N is pretty large. Please show a complete code with the problem. That means the calling routine as well. – lastchance Aug 09 '23 at 14:03
  • This is unreadable. Please edit your question to add any additionnal detail or code, rather than putting them in comments. – PierU Aug 09 '23 at 14:03
  • 1
    I get it, anyway. The argument `N` is declared as `integer*8`, but you are passing `16`, which is a default `integer`. – PierU Aug 09 '23 at 14:05
  • I have now edited the question. – R2197 Aug 09 '23 at 14:05
  • 1
    That new code won't compile - you haven't declared all your arguments. Please give the ACTUAL code. – lastchance Aug 09 '23 at 14:06
  • The call is now missing in your updated question. – PierU Aug 09 '23 at 14:07
  • Edited again. @lastchance the actual code is multiple files and pretty huge. And the thing is all of it was working, including this k1 array. But now somehow it has stopped. – R2197 Aug 09 '23 at 14:08
  • I gave you the origin of the problem in an above comment: `16` is not an `integer*8`, so `N` is not correctly interpreted in the subroutine. Print it and you'll see. – PierU Aug 09 '23 at 14:12
  • Quick update. It now works with Integer, instead of Integer*8. Could someone explain the difference? I thought that it doesn't make a difference. Thanks everyone for the replies. – R2197 Aug 09 '23 at 14:13
  • It's often very important to see the actual code, not a part of the code or a fake code. – PierU Aug 09 '23 at 14:13
  • 1
    Why did you imagine that `integer` and `integer*8` was the same thing? An `integer` is generally 32 bits on most systems, while `integer*8` is 64 bits. Note that `integer*8` or `real*8` are non-standard in Fortran. – PierU Aug 09 '23 at 14:17
  • If you passed it a 32-bit integer and it expected a 64-bit integer how did it compile in the first place? All 3 compilers that I tried threw it out for type mismatch. – lastchance Aug 09 '23 at 14:19
  • 2
    See [Fortran: integer*4 vs integer(4) vs integer(kind=4)](https://stackoverflow.com/questions/3170239/fortran-integer4-vs-integer4-vs-integerkind-4/3170438). I suggest to read it thoroughly. – Vladimir F Героям слава Aug 09 '23 at 14:26
  • Also, when solving problems like these, always compile your code for debugging. With `gfortran -g -fbacktrace -fcheck=all` and you can also add `-Wall`. With Intel use `ifort -g -traceback -check` and you can also add `-warn`. It is really important. Your program may look like it running correctly, but it may be buggy and giving incorrect results. – Vladimir F Героям слава Aug 09 '23 at 15:25

0 Answers0