Lately I received the following error in my Fortran code
Program received signal SIGSEGV: Segmentation fault - invalid memory reference.
Backtrace for this error:
#0 0x2AD9B0F8FE08
#1 0x2AD9B0F8EF90
#2 0x2AD9B12D44AF
#3 0x401A3E in MAIN__ at tstreadin.f90:?
and my code as follows
Program www
implicit none
integer ::i,j,rows,cols,row
real(kind=8) ::x,y,z
real(kind=8),allocatable::mat(:,:),xrange(:),yrange(:)
real(kind=8),allocatable::pot_bar(:,:),acc_bar_x(:,:),acc_bar_y(:,:)
real(kind=8),allocatable::pot_sph(:,:),acc_sph_x(:,:),acc_sph_y(:,:)
rows=2250000
cols=8
row=1500
allocate(mat(cols,rows))
allocate(xrange(row),yrange(row),pot_bar(row,row))
allocate(acc_bar_x(row,row),acc_bar_y(row,row))
allocate(pot_sph(row,row),acc_sph_x(row,row),acc_sph_y(row,row))
open(24,file='pot.txt',status='old',form='Formatted', access='SEQUENTIAL')
do i=1,rows,1
read(24,*)mat(:,i)
enddo
close(24)
do i=1,rows,row
xrange(i)=mat(1,i)
enddo
do i=1,row,1
yrange(i)=mat(2,i)
enddo
do i=1,row,1
do j=1,row,1
pot_bar(j,i)=mat(3,j+(i-1)*1500)
acc_bar_x(j,i)=mat(4,j+(i-1)*1500)
acc_bar_y(j,i)=mat(5,j+(i-1)*1500)
pot_sph(j,i)=mat(6,j+(i-1)*1500)
acc_sph_x(j,i)=mat(7,j+(i-1)*1500)
acc_sph_x(j,i)=mat(8,j+(i-1)*1500)
enddo
enddo
print*,xrange
print*,yrange
end Program www
I want to input data from the ASCII profile to the arrays,so I write the code for test. This is my first time using Fortran, and I completely can't understand why the error appeared.
The array xrange only has 1500 elements allocated. However in the following
do i=1,rows,row
xrange(i)=mat(1,i)
enddo
you are attempting to access an element of xrange with an index far greater than 1500 (rows >> 1500). Hence the invalid memory reference.
Related
I am learning C programming from "Learn c the hard way by Zed Shaw". He asks the learner to try and break their own code.
So I tried the following C code and thought printing more values that I gave argv will break it but it did not until later.
#include<stdio.h>
int main(int argc, char *argv[])
{
int i = 0;
printf("This is argc: %d\n",argc);
printf("This is argv[argc]: %s\n",argv[argc]);
printf("This is argv[0]: %s\n",argv[0]);
for(i=argc;i<100;i++)
printf("This is argv[%d]: %s\n",i,argv[i]);
for(i=1;i<argc;i++)
{
printf("arg %d: %s\n",i,argv[i]);
}
return 0;
}
When I try to print argv upto 100:
I see the following when I was expecting some kind of out of bound or segmentation fault.
./exp10_so These are cmd args
This is argc: 5
This is argv[argc]: (null)
This is argv[0]: ./exp10_so
This is argv[5]: (null)
This is argv[6]: TERMINATOR_DBUS_NAME=net.tenshu.Terminator21a9d5db22c73a993ff0b42f64b396873
This is argv[7]: GTK_RC_FILES=/etc/gtk/gtkrc:/home/ab/.gtkrc:/home/ab/.config/gtkrc
This is argv[8]: _=/home/ab/Projects/learn_c_the_hard_way/./exp10_so
This is argv[9]: LANG=en_IN
This is argv[10]: GTK3_MODULES=xapp-gtk3-module
This is argv[11]: XDG_CURRENT_DESKTOP=KDE
This is argv[12]: QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1
This is argv[13]: LC_IDENTIFICATION=en_IN
This is argv[14]: XCURSOR_THEME=breeze_cursors
This is argv[15]: XDG_SESSION_CLASS=user
This is argv[16]: XDG_SESSION_TYPE=x11
This is argv[17]: SHLVL=1
This is argv[18]: TERMINATOR_UUID=urn:uuid:4496f24b-8a64-43af-ab5a-03fc7e722242
This is argv[19]: DESKTOP_SESSION=plasma
This is argv[20]: LC_MEASUREMENT=en_IN
This is argv[21]: OLDPWD=/home/ab/Projects
This is argv[22]: HOME=/home/ab
This is argv[23]: KDE_SESSION_VERSION=5
This is argv[24]: USER=ab
This is argv[25]: TERMINATOR_DBUS_PATH=/net/tenshu/Terminator2
This is argv[26]: SESSION_MANAGER=local/tgh:#/tmp/.ICE-unix/2372,unix/tgh:/tmp/.ICE-unix/2372
This is argv[27]: XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session1
This is argv[28]: DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
This is argv[29]: XDG_VTNR=1
This is argv[30]: XDG_SEAT=seat0
This is argv[31]: LC_NUMERIC=en_IN
This is argv[32]: BROWSER=/usr/bin/firefox
This is argv[33]: GTK_MODULES=canberra-gtk-module
This is argv[34]: XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0
This is argv[35]: XDG_DATA_DIRS=/home/ab/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share:/usr/share:/var/lib/snapd/desktop
This is argv[36]: XDG_SESSION_DESKTOP=KDE
This is argv[37]: VTE_VERSION=6401
This is argv[38]: KDE_SESSION_UID=1000
This is argv[39]: LC_TIME=en_IN
This is argv[40]: MAIL=/var/spool/mail/ab
This is argv[41]: LOGNAME=ab
This is argv[42]: QT_AUTO_SCREEN_SCALE_FACTOR=0
This is argv[43]: LC_PAPER=en_IN
This is argv[44]: PATH=/usr/local/nginx/sbin:/home/ab/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/var/lib/snapd/snap/bin
This is argv[45]: QT_SCREEN_SCALE_FACTORS=LVDS1=1;DP1=1;HDMI1=1;VGA1=1;VIRTUAL1=1;
This is argv[46]: XDG_RUNTIME_DIR=/run/user/1000
This is argv[47]: SHELL=/bin/zsh
This is argv[48]: XDG_SESSION_ID=2
This is argv[49]: LC_MONETARY=en_IN
This is argv[50]: GTK2_RC_FILES=/etc/gtk-2.0/gtkrc:/home/ab/.gtkrc-2.0:/home/ab/.config/gtkrc-2.0
This is argv[51]: LC_TELEPHONE=en_IN
This is argv[52]: EDITOR=/usr/bin/nano
This is argv[53]: COLORTERM=truecolor
This is argv[54]: MOTD_SHOWN=pam
This is argv[55]: KDE_APPLICATIONS_AS_SCOPE=1
This is argv[56]: PAM_KWALLET5_LOGIN=/run/user/1000/kwallet5.socket
This is argv[57]: KDE_FULL_SESSION=true
This is argv[58]: XAUTHORITY=/home/ab/.Xauthority
This is argv[59]: LC_NAME=en_IN
This is argv[60]: DISPLAY=:0
This is argv[61]: LC_ADDRESS=en_IN
This is argv[62]: PWD=/home/ab/Projects/learn_c_the_hard_way
This is argv[63]: XCURSOR_SIZE=24
This is argv[64]: TERM=xterm-256color
This is argv[65]: ZSH=/home/ab/.oh-my-zsh
This is argv[66]: PAGER=less
This is argv[67]: LESS=-R
This is argv[68]: LSCOLORS=Gxfxcxdxbxegedabagacad
This is argv[69]: LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=00:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.zst=01;31:*.tzst=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.wim=01;31:*.swm=01;31:*.dwm=01;31:*.esd=01;31:*.jpg=01;35:*.jpeg=01;35:*.mjpg=01;35:*.mjpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.webp=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.m4a=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.oga=00;36:*.opus=00;36:*.spx=00;36:*.xspf=00;36:
This is argv[70]: LD_LIBRARY_PATH=/usr/local/lib
This is argv[71]: (null)
AddressSanitizer:DEADLYSIGNAL
=================================================================
==69851==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000021 (pc 0x7f3c30d7b4c6 bp 0x7ffe273b2ba0 sp 0x7ffe273b22e8 T0)
==69851==The signal is caused by a READ memory access.
==69851==Hint: address points to the zero page.
#0 0x7f3c30d7b4c6 in __sanitizer::internal_strlen(char const*) /build/gcc/src/gcc/libsanitizer/sanitizer_common/sanitizer_libc.cpp:167
#1 0x7f3c30d0d057 in printf_common /build/gcc/src/gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors_format.inc:545
#2 0x7f3c30d0d41c in __interceptor_vprintf /build/gcc/src/gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:1639
#3 0x7f3c30d0d517 in __interceptor_printf /build/gcc/src/gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:1697
#4 0x562c5e03f290 in main /home/ab/Projects/learn_c_the_hard_way/exp10_so.c:13
#5 0x7f3c30b0ab24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
#6 0x562c5e03f0bd in _start (/home/ab/Projects/learn_c_the_hard_way/exp10_so+0x10bd)
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /build/gcc/src/gcc/libsanitizer/sanitizer_common/sanitizer_libc.cpp:167 in __sanitizer::internal_strlen(char const*)
==69851==ABORTING
A segmentation fault happens when the code try to access a memory region that is not available.
Accessing an array out of bounds doesn't means that the memory before or after the area occupied by the array is not available: The compiler or the runtime usually put all varibales or data in general in a given block of memory. If your array is the last item of such a memory block, the accessing it with a to big index will produce a Segmentaion Fault but is the array is in the middle of the memory block, you will just access memory used for other data, giving unexpected result and undefined behavior.
If the array (In may example, but valid for anything) is written, accessing available memory will not produce a segmentation fault but will overwrite something else. It may produce unexpected results or crash or segmentation fault later! This kind of bug is frequently very difficult to find because the unexpected result/behavior looks completely independent of the root cause.
I am currently trying to get a fortran FE (finite element) code to work with openmp. I have a loop over all elements, ie that I want to work in parallel. Here is a simplified part of the code that is not working
!$omp parallel do default(none) shared(nelm,A,res,enod) private(ie,Fe,B,edof)
do ie=1,nelm
call calcB(B,A(:,ie))
call calcFe(Fe,B)
write(*,*) Fe !writes Fe=40d0, this is correct
call getEdof(edof,enod(:,ie))
!$OMP CRITICAL
res(edof)=res(edof)+fe
!$OMP END CRITICAL
enddo
!$omp end parallel do
The purpose of the code is to calculate a force Fe and then adding it to res at edof. The force is calculated with calcFe, and the calculated force is correct, but the resulting res is incorrect after the loop.
If I replace calcFe with simply Fe=40d0 then add it to res the result is correct after the loop
!$omp parallel do default(none) shared(nelm,A,res,enod) private(ie,Fe,B,edof)
do ie=1,nelm
call calcB(B,A(:,ie))
Fe=40d0
call getEdof(edof,enod(:,ie))
!$OMP CRITICAL
res(edof)=res(edof)+fe
!$OMP END CRITICAL
enddo
!$omp end parallel do
What causes this error? In both cases Fe=40d0 is declared private but only one of them gives the correct result. Instead of using !$ CRITICAL I could use reduction but it gives the same error. In the program several large and sparse matrices are also used but the are passive/ not used during the loop. My supervisor has had problems with using openmp and sparse matrices before and suspects that they are using the same memory. If the error is not apparent what debugger is best to use? Im a novice to both fortran ,openmp and programing in general.
Im using ifort to compile and my OS is ubuntu.
EDIT: Added simplified code that you can run, although this code works
In the code there are two loops, on parallel and one serial, to they should give the same result, res and res2
program main
use omp_lib
implicit none
integer :: ie, nelm,enod(4,50*50),edof(12),i,j,k
double precision ::B(12,8),fe(12),A(12,12,2500),res(2601*3),res2(2601*3),finish,start
!creates enod
i=1
do j=1,50
ie=j
do k=1,50
nelm=k
enod(:,i)=(/ 51*(nelm-1)+1+ie-1, 51*(nelm-1)+1+ie, 51*(nelm)+1+ie-1, 51*(nelm)+1+ie /)
i=i+1
end do
end do
A=1d0
res2=0d0
nelm=2500
start=omp_get_wtime()
!$omp parallel do default(none) shared(nelm,A,enod) private(ie,fe,edof,B) reduction(+:res2)
do ie=1,nelm
call calcB(B,A(:,:,ie))
call calcFe(fe,B) !the calculated fe is always 2304
!can write fe=2304 to get correct result with real code
call getEdof(edof,enod(:,ie))
res2(edof)=res2(edof)+fe
end do
!$omp end parallel do
finish=omp_get_wtime()
write(*,*) 'time: ', finish-start
res=0d0
nelm=2500
start=omp_get_wtime()
do ie=1,nelm
call calcB(B,A(:,:,ie))
call calcFe(fe,B)
call getEdof(edof,enod(:,ie))
res(edof)=res(edof)+fe
end do
finish=omp_get_wtime()
write(*,*) 'time: ', finish-start
write(*,*) 'difference: ',sum(res2-res)
write(*,*) sum(res2)
stop
end program main
subroutine calcB(B,A)
double precision ::B(12,8),A(12,12),C(12)
integer ::gp
C=1d0
do gp=1,8
B(:,gp)=matmul(A,C)
end do
end subroutine calcB
subroutine calcFe(fe,B)
double precision ::fe(12),B(12,8),D(12,12)
integer ::gp
fe=0d0
D=2d0
do gp=1,8
fe=fe+matmul(D,B(:,gp))
end do
end subroutine calcFe
subroutine getEdof(edof,enod)
implicit none
integer,intent(in) :: enod(4)
integer,intent(out):: edof(12)
edof=0
edof(1:3) =(/ enod(1)*3-2, enod(1)*3-1, enod(1)*3 /)
edof(4:6) =(/ enod(2)*3-2, enod(2)*3-1, enod(2)*3 /)
edof(7:9) =(/ enod(3)*3-2, enod(3)*3-1, enod(3)*3 /)
edof(10:12)=(/ enod(4)*3-2, enod(4)*3-1, enod(4)*3 /)
end subroutine getedof
And the make file
FF = ifort -O3 -openmp
OBJ1 = main.f90
ls: $(FORT_OBJS)
$(FF) -o exec $(OBJ1)
Unfortunately this piece of code works, so i'm unable to replicate the error. res2 and res are calculated in serial and parallel. In my real program I have put all values to 1d0 in order to get a constant fe. The calulated fe is correct, if I add a write(*,*) fe after calcFe I see that the values are correct. I then add these values to res2 and compare them with the serial res. They are then different by a large margin, so there is no numerical roundoff error. If I simply declare fe=2304 in my main program I get the correct answer even though fe already is 2304 when write is used.
In the my real program all the subroutines are in different modules, do I need to take any special care because of this?
Also in one of the modules some global variables are used, they are read only but since they are not declared in the subroutine they are not automaticly made private? This should be no issue since I put all variables used to to calulate fe to a constant, the global variables are not used directly to calculate fe
Solved it, it started working when I added -openmp to the makefile for my modules. Apparently the modules needs to be compiled with -openmp and not just the main file.
gdb was reporting that my C code was crashing somewhere in malloc(), so I linked my code with Electric Fence to pinpoint the actual source of the memory error. Now my code is segfaulting much earlier, but gdb's output is even more confusing:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x30026b00 (LWP 4003)]
0x10007c30 in simulated_status (axis=1, F=0x300e7fa8, B=0x1003a520, A=0x3013b000, p=0x1003b258, XS=0x3013b000)
at ccp_gch.c:799
EDIT: The full backtrace:
(gdb) bt
#0 0x10007c30 in simulated_status (axis=1, F=0x300e7fa8, B=0x1003a520, A=0x3013b000, p=0x1003b258, XS=0x3013b000)
at ccp_gch.c:799
#1 0x10007df8 in execute_QUERY (F=0x300e7fa8, B=0x1003a520, iData=0x7fb615c0) at ccp_gch.c:836
#2 0x10009680 in execute_DATA_cmd (P=0x300e7fa8, B=0x7fb615cc, R_type=0x7fb615d0, iData=0x7fb615c0)
at ccp_gch.c:1581
#3 0x10015bd8 in do_volley (client=13) at session.c:76
#4 0x10015ef4 in do_dialogue (v=12, port=2007) at session.c:149
#5 0x10016350 in do_session (starting_port=2007, ports=1) at session.c:245
#6 0x100056e4 in main (argc=2, argv=0x7fb618f4) at main.c:271
The relevant code (slightly modified due to reasons):
796 static uint32_t simulated_status(
797 unsigned axis, struct foo *F, struct bar *B, struct Axis *A, BAZ *p, uint64_t *XS)
798 {
799 uint32_t result = A->status;
800 *XS = get_status(axis);
801 if (!some_function(p)) {
802 ...
The obvious thing to check would be whether A->status is valid memory, but it is. Removing the assignment pushes the segfault to line 800, and removing that assignment causes some other assignment in the if-block to segfault. It looks as though either accessing an argument passed to the function or writing to a local variable is what's causing the segfault, but everything points to valid memory according to gdb.
How am I to interpret this? I've never seen anything like this before, so any suggestions / pointers in the right direction would be appreciated. I'm using GNU gdb 6.8-debian, Electric Fence 2.1, and running on a PowerPC 405 (uname reports Linux powerpmac 2.6.30.3 #24 [...] ppc GNU/Linux).
I'm guessing, but your symptoms are similar to what could happen in a stack overflow situation. The -fstack-protector suggestion in the comments is on the right track here. I'd recommend adding the -fstack-check option as well.
If the SEGV is occurring because of writes to the guard page protecting the stack then an info registers and info frame in gdb would help confirm if this is the case.
I have a fortran program. A subroutine is as below.The program gives segmentation fault after executing line 1434 and printing the below:
i: 115 256 2
Segmentation fault (core dumped)
The parameters are n1=258, n2=258, and n3=258. nr=46480. Why does segmentation fault happen?
75 double precision u(nr),v(nv),r(nr),a(0:3),c(0:3)
76 common /noautom/ u,v,r
......
196 call zero3(u,n1,n2,n3)
......
1418 subroutine zero3(z,n1,n2,n3)
1419
1420 c---------------------------------------------------------------------
1421 c---------------------------------------------------------------------
1422
1423 implicit none
1424
1425
1426 integer n1, n2, n3
1427 double precision z(n1,n2,n3)
1428 integer i1, i2, i3
1429
1430 !$omp parallel do default(shared) private(i1,i2,i3)
1431 do i3=1,n3
1432 do i2=1,n2
1433 do i1=1,n1
1434 print*,"i: ",i1, " ", i2 , " " ,i3
1435 z(i1,i2,i3)=0.0D0
1436 enddo
1437 enddo
1438 enddo
1439
1440 return
1441 end
Your variable definition sets aside storage for 46480 double in array u (and also sets aside as much space for v and r.
Your function call to zero3() claims there is enough storage for 258*258*258 = 17173512 doubles in the array you are passing.
When it tries to access an element far enough outside the bounds of the actual array, the program crashes — you are trying to access memory that is not allocated to your program.
Either you need to change nr to be a smaller number (35*35*35 = 42875, so zero3(u, 35, 35, 35) should be safe (non-crashing), or you need to allocate more space for u:
double u(258,258,258)
or something similar (it's a while since I last wrote Fortran; the standard was Fortran 77 at the time).
I have a code that worked fine until now with 3 million atom-sized static arrays.
For practical reasons, I have to go now to 10 million atom sized arrays. At first, my compiler did not allow me to do this, but I managed to find a way around with the following flags ifort -mcmodel medium -shared-intel -traceback kubo.f. It runs, but something very strange is happening. My matrix contains 11 609 198 elements.
I check the value of my coordinates as follows (the value of 4 669 671 is the first time it goes wrong):
print*, x(4669671),y(4669671),zcoord(4669671)
followed by several lines where the value of x, y and zcoord is not changed or anything. Then, I enter a loop on these 3 vectors where the value of x, y and zcoord will be used but not changed. I print the 3 values again, and suddenly, the 3 values are changed?!
Is there something I'm missing for large arrays?
EDIT : Here the complete code (as I don't know what is a race condition, I don't know If I'm allowed to delete some parts to make it more readable) :
open(1,FILE='fort.10')
read(1,*)NAT1
write(*,*)'Lecture de Nat1=',NAT1
read(1,*)
do i=1,nsites
read(1,*)parcon(i),x(i),y(i),zcoord(i)
enddo
print*, x(4663659),y(4663659),zcoord(4663659)
print*, x(4663663),y(4663663),zcoord(4663663)
!HERE
print*, x(4669671),y(4669671),zcoord(4669671)
print*, x(4673254),y(4673254),zcoord(4673254)
iflag=0
iflagg=0
impurityCounter=0
C4Counter=0
do i=1,nsites
nvo=0
if(i.le.(nsites-93998)) then
jj=i-10000
jjj=i+10000
do j=jj,jjj,1
if((j.gt.0).and.(j.le.(nsites-93998))) then
dist=dsqrt((x(j)-x(i))**2+(y(j)-y(i))**2
. +(zcoord(j)-zcoord(i))**2)
if((dist.lt.(1.11*aCC))
. .and.(j.ne.i).and.(dist.gt.0.1)) then
nvo=nvo+1
v(i,nvo)=j
if(i.eq.4663660) then
!THERE
print*, dist,j,x(j),y(j),zcoord(j)
endif
endif
endif
enddo
jjjj=nsites-93998+1
do j=jjjj,nsites,1
dist=dsqrt((x(j)-x(i))**2+(y(j)-y(i))**2
. +(zcoord(j)-zcoord(i))**2)
if((dist.lt.(1.11*aCC)).and.(j.ne.i).and.(dist.gt.0.1)) then
nvo=nvo+1
v(i,nvo)=j
endif
enddo
else
do j=1,nsites
dist=dsqrt((x(j)-x(i))**2+(y(j)-y(i))**2
. +(zcoord(j)-zcoord(i))**2)
if((dist.lt.(1.11*aCC)).and.(j.ne.i).and.(dist.gt.0.1)) then
nvo=nvo+1
v(i,nvo)=j
endif
enddo
endif
if ((nvo.eq.2).AND.(parcon(i).eq.'C')) then
iflag=iflag+1
vpb(iflag)=i
endif
if((nvo.eq.1).AND.(parcon(i).eq.'C')) then
iflagg=iflagg+1
vpbb(iflagg)=i
endif
!count the number of impurities
if((nvo.eq.2).AND.(parcon(i).eq.'O1')) then
impurityCounter=impurityCounter+1
impurityVector(impurityCounter)=i
endif
if((nvo.eq.2).AND.(parcon(i).eq.'O2')) then
impurityCounter=impurityCounter+1
impurityVector(impurityCounter)=i
endif
!If nvo equals 4, there is a BAD counting!
if(nvo.eq.4) then
print*, v(i,1)
print*, v(i,2)
print*, v(i,3)
print*, v(i,4)
print*, x(i), y(i)
endif
if(nvo.eq.5) then
C4Counter=C4Counter+1
C4Vector(C4Counter)=i
endif
enddo
I added !HERE and !THERE to show you where are the two places I print the x, y and zcoord of the element 4669671...
I'm not familiar with ifort, but I assume it has an option for checking array bounds. Turn it on.
Variables changing their value without you actually assigning something to them are often a sign that some other variable is referenced outside of its declared bounds.
Do you get any error message besides "killed"? Maybe with bounds checking the memory usage is once again too large. A common problem with large arrays is exceeding the available stack space ... see Stack overflow in Fortran 90. How are the variables declared? Are all the integers at least four bytes to hold these large values? If you are overwriting memory from exceeding an array bound in this block of code, it has to be from storage to an array in this block (v as suggested by #Jonathan Dursi, vpb, vpbb) ... obvious, but you can insert your own index checking code if the compiler option bounds checking still results in an executable that is too large. Place an IF statement before each array assignment in the code that is executed from before to after the problem occurs.