Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
28870 Discussions

A breakpoint instruction (__debugbreak() statement or a similar call) was executed

hamza2hb
Beginner
6,391 Views

I’m running a Fortran visual studio 2022 console application and the Fortran code crashes with “A breakpoint instruction (__debugbreak() statement or a similar call) was executed” and when I press continue it gives me " forrtl: severe (408): fort: (11): Subscript #3 of the array XT has value 0 which is less than the lower bound of 1 "

I don’t know where is the problem exactly here ? Note the the main code isn't my work and that it compiled before by the former editor 

 

f1.png

 

f2.png

 

 

0 Kudos
6 Replies
jimdempseyatthecove
Honored Contributor III
6,382 Views

Apparently kk has a value of 1. Thus kk-1 == 0 and is an invalid 3rd index to xt which lower bound is 1.

This usually indicates that you code is missing a special case section for the perimeter of the (volume?).

 

Jim Dempsey

0 Kudos
hamza2hb
Beginner
6,284 Views

I did all the best I can but I didn't figure out the solution, this is the file if you can do it for me

 https://github.com/dansteingart/dualfoil5/tree/master/df5.1

0 Kudos
andrew_4619
Honored Contributor III
6,261 Views

Well I spent 10 minutes on this and concluded:

at line 2721 it throws and error because KK=1 and kk-1 i.e. zero is being used as an array subscript which is out of range i.e. 1 is the smallest OK value.

 

2721 is subroutine 'comp' called at line 860 of the main program. The value of KK passed is variable K in the main program.

K seems to be the iteration number  and it is initialised to 1 at line 744 and is not changed prior to the fatal comp call.

 

There are various code paths that could modify K but they don't happen. I would this guess that a) the input data supplied is wrong  or b) There are code bugs based on the many old school and non-standard Fortran, this latter one is quite probable looking at the code. which seems circa 1994 with some later mods. 

 

I cannot really help any further as it would need an understanding of the code and probably take a lot of time. 

 

EDIT. I noticed after I posted this that  a few minutes earlier mecej4 has posted pretty much identical findings and conclusions, which I guess is not surprising if you follow a logical fault finding route. Maybe try to contact the github contributor to find out how they built and run the program might help.

0 Kudos
Steve_Lionel
Honored Contributor III
6,378 Views

Additional info: The "breakpoint instruction..." message isn't the important part. If you see this, look at the console window (which you did, thanks!) to see what triggered the breakpoint. What you got here was an error for an out-of-bounds array reference, as Jim says.

0 Kudos
JohnNichols
Valued Contributor III
6,355 Views

This is a common problem in Fortran. Suggestions

put in an if statement before that call and stop the execution and print out the zero value, or debug on the print statement and look to see the source. 

work backwards from the line looking for the error that gives you a zero value, it is tedious but it often works., using print statements seeking the source of the zero unless it is obvious  I would leave the if statement in after you fix it so it happens from another source it should at least print something. 

 

0 Kudos
mecej4
Honored Contributor III
6,268 Views

It is not reasonable for you to ask us to fix your program for you. The program has many bugs other than the one that you have run into. It uses many variables without initializing them. The program may expect all variables to be initialized to zero and given the SAVE attribute.

The present bug is caused by the following statements:

  • The variable k is set = 1 on line 744
  • Subroutine Comp is called on line 868, with the third argument, k, still equal to 1
  • There are numerous lines later on where kk-1 is used as an index, which is an error since the lower bound is (by default) 1.

The program may have worked in the past and may have given reasonable results despite these bugs. See if you can find out which computer the code was run on successfully, what compiler was used and what the options specified were. Obtain a test data and the expected results for it, if possible, and if you think that this program is worth putting so much effort into. Fixing the program is something that should be undertaken only by a person with good understanding of the subject matter -- electrochemistry in this case.

0 Kudos
Reply