After a successful migration of CVF to IVF, an error appears...

[emreka82]

Hi,

I recently download and install the IVF composer XE 2011 and Visual Studio 2011 to my newly formatted computer. I was using CVF to my compiling issues and because of the lack of support during CVF use, I decided to switch forward to IVF. I step-by-step apply "the migration from CVF to IVF" article of the forum. After the building and running the program (...exe) everything "seems to be " right. But at some point of the running procedure, I encountered an error and the program stopped. The error is:

On the command:

forrtl: sever (408): fort: (3): Subsxcript #1 of the array INB has value 0 which is less than the lower bound of 1

then some exe and dll file names under the image header.

On the pop-up window:

Debug Assertion Failed !

Program:....exe
File: f:\\dd\\vctools\\ctr_bld\\self_x86\\crt\\src\\winsig.c
Expression: ("Invalid signal or error", 0)

For information on how your program can cause an assertion failure, see the Visual Cplusplus documentation assets.

In the light of my searches in the forum, I change "Stack Reserve Size" to 100000000 and heap-array value to 0. Nothing has changed...

Note: Why is thi assertion error related to Visual Cplus plus instead of Visual Fortran ? I did not understand...

[Steven_L_Intel1]

Ignore the Visual C++ popup- that's just a side effect of the Fortran error report. Look at the Fortran error and determine if it is valid. It should stop in the debugger when this occurs.

[emreka82]

I was using "Start without debugging" mode . After your suggestion I will choose "start with debugging" then try to understand where the problem is. I will write down the results, thanks.

[emreka82]

I start the project with debugging. It gives me this message:

"(file name).exe has triggered a breakpoint", which has two choices ( break or continue) when I continue, the program exits with this message:

'(file name).exe': Loaded 'D:\...\...\Debug\(file name).exe', Symbols loaded.
'(file name).exe': Loaded 'C:\Windows\System32\ntdll.dll', Cannot find or open the PDB file
'(file name).exe': Loaded 'C:\Windows\System32\kernel32.dll', Cannot find or open the PDB file
'(file name).exe': Loaded 'C:\Windows\System32\KernelBase.dll', Cannot find or open the PDB file
'(file name).exe': Loaded 'C:\Windows\System32\imagehlp.dll', Cannot find or open the PDB file
'(file name).exe': Loaded 'C:\Windows\System32\msvcrt.dll', Cannot find or open the PDB file
'(file name).exe': Loaded 'C:\Windows\System32\dbghelp.dll', Cannot find or open the PDB file
(file name)exe has triggered a breakpoint
The program '[3332] (file name).exe: Native' has exited with code 408 (0x198)."

I cannot understand why it does not run properly...I was running the project which was fine on CVF.

[Steven_L_Intel1]

The messages you cite are not interesting. What is interesting is what is in the console window. Continuing from the error is not possible.

Have you determined that the array bounds error is incorrect?

[emreka82]

Yes the array bounds error is incorrect, since the code works in CVF, and does not stop running at that point.

Another thing is that, the reason to migrate from CVF to IVF was the limited iteration number in CVF, at larger iteration numbers (over 1000) CVF was failing. But here in IVF the much more larger iteration numbers can run (30000), but now it stops when a specific code encountered, the code is for a computational method and yes I am sure that it works right, at least in CVF.

Edit: I change the -heap arrays to 0 to enable allocatable arrays, and it also does not work....

[Steven_L_Intel1]

Sorry, but as many customers have found, a program "working" in compiler X does not guarantee that the program is correct. Many customers find that Intel Fortran reveals errors that were hidden by other programs.

One thing that sometimes bites CVF users is a change in how local subroutine variables are treated. CVF applied SAVE semantics to these by default, but Intel Fortran does not. You may want to try setting the property Data > Local variable storage > All variables SAVE and see if that helps.

If not, please provide us with a copy of the application and we'll be glad to take a look. You can attach a ZIP to a reply here or submit through Intel Premier Support. Please be sure to provide everything needed to build and run the application, and instructions on reproducing the error.

[Lorri_M_Intel]

RE: Yes the array bounds error is incorrect, since the code works in CVF, and does not stop running at that point

One other thing to note: by default, the IVF Debug configuration sets the /check:bounds diagnostic.
By default, CVF did not. If you build your CVF application with /check:bounds, you could see the same diagnostic.

-- Lorri

[mecej4]

The behaviors that you describe (with two different compilers) strongly indicate that there are some bugs in your program that occur at unpredictable times and are hard to pinpoint. If the effect of the errors is to cause only moderate errors in the results most of the time, they will go unnoticed. When a large error is noticed or causes program abort, it can be very mystefying.

In such circumstances, it is incorrect to blame the failures upon the compilers.

[emreka82]

Lorri, should I change it to /check:unbounds ? If so, how ?

[emreka82]

@ Steve

I already have changed the setting to All Variables SAVE...If there aren't any suggestions today and after I try to get rid of the problem all day, if I cannot accomplish any solution then I guess I will use premier support tomorrow and wait for your response...

Thanks.

[IanH]

It is highly probable that your program has a bug. The message that you get when your program runs gives you pretty specific information about the problem ("subscript #1 of the array INB has value 0 which is less than the lower bound of 1"). You need to understand why the compiler/program thinks the subscript is out of range and (almost certainly) make changes to your program or its input to fix this situation.

Run your program from within visual studio with debugging, as you describe in reply #3. When the error message pops up select "Break" (instead of selecting "Continue"). You can then inspect the values of variables in your program to try and understand what is going on at the time the error is generated. If the problem is initiated at an earlier point in program execution then you may need to run-run the program with appropriate breakpoints set and "step" execution up to the point of the error message in order to follow your program's logic.

Turning off bounds checking doesn't remove the bug, it just hides it. Perhaps that bug has no or little effect, perhaps it has been causing huge errors in your program's output - until you fix it you won't know!

Advice on this forum beyond the general debugging advice above is going to require lots more detail from you - for example you need to show us "relevant" part of the code and the values of any referenced values in that code. In some (most?) cases the "relevant" part is the entire program.

[John_Campbell]

Your symptoms could indicate the program was previously developed assuming static allocation of local variables.
Having a zero subscript most commonly occurs if the previous value of the subscript, defined in a previous call to the subroutine, has now been lost. This can also happen if the logic skips a default setting for the subscript variable, utilising the previous value when static allocation was provided.

Look at the SAVE compile option for local variables, which can be selected by /Qsave. You should confirm this is being activated.

The run time has identified that the subscript is zero (probably it has not been defined). You must accept this.Your response is to find out why. There must be a reason. You could put in code to write out key variables that control the program logic, prior to this event, to see how it got to this situation.

Assuming static allocation of local variables is a common problem when changing to a compiler which has dynamic allocation (as required by the Fortran standard).

[tropfen]

Hello,

Just an idea.

There is one point where we had problems during the conversion from CVF to IVF. This has resulted in the same error. We had lines like the following:


integer :: i,array(10)
if ((i/=0).and.(array(i)/=-999)) then

In CVF this was working (Even it was not correct). In IVF this is not working.

Frank

[Arjen_Markus]

With constructions like that you rely on "short circuiting" - the Fortran standard is explicit about
this: such short circuiting is NOT guaranteed to work. The rationale is that short circuiting causes
optimisation problems and more complicated object code.

Regards,

Arjen

[anthonyrichards]

Always add IMPLICIT NONE to your declarations, then explicitly declare the types of all variables used in your program(s). Also remember that in CVF debug, most variables are initialised to zero, but this does not happen in release mode. Find all uninitialised variables, Use SAVE to make sure local variables are saved between calls, if that is what your code implicitly assumes, as IVF does not automatically save them, whereas CVF did by default. Then show us ALL the error messages you get.

BTW, using IF(TEST1.AND.TEST2), where TEST2 would give problems (i.e. cause a memory-acess crash) if TEST1 is not true does not avoid the problem, as you cannot guarantee that TEST2 will not be evaluated by the compiler if TEST2 fails. BOTH test results will probably be evaluated BEFORE they are ANDed. Hence use the construct

IF(test1) then
If(test2) then
...
...
endif
endif

[jeremy_h]

This suggestion of Arjen's is probably the right one. If the code uses short-circuit eval in one place, it probably uses it all over the place.

This was our unfortunate experience. This was a nasty shock for us also. In our case it will introduce corner-case latent defects for the next ten years. I fully agree that short-circuit evaluation has various theoretical uncertainties and inconsistencies, but we have exchanged this for actual defects and, worse, latent defects that escape compiler detection. We are satisfied overall with our IVF migration, but this remains one of the issues that the old-timer CVF guys snipe at us for changing their compiler on them.

[John_Campbell]

It's worth contemplating the meaning of the claim that the Fortran 95/03/08 standard supports older standards, but the IVF compiler (and most other compilers available) do not support older complers which did not conform to the standard (ie had their own extensions). In this case even those they were developed from.

Static storage of local arrays and the order of execution of a grouped logical test are two examples of coding techniques that are discussed in most Fortran 90+ textbooks.

John

[j_clausen]

Couldthe problemsbe related to the topic of this post: http://software.intel.com/en-us/forums/showthread.php?t=66020&o=a&s=lr ?

Best regards J_Clausen

[emreka82]

@ John

Yes, SAVE compile option is /Qsave.

By the way, after all the changes applied on the code options ( check:bounds, save option, etc...), it works fine :)

The only problem (i guess it is a problem) after the code runs and gives the necessary outputs, on the ouptu command it says "Show output from debug":

'(file name).exe': Loaded 'D:\...\...\Debug\(file name).exe', Symbols loaded.
'(file name).exe': Loaded 'C:\Windows\System32\ntdll.dll', Cannot find or open the PDB file
'(file name).exe': Loaded 'C:\Windows\System32\kernel32.dll', Cannot find or open the PDB file
'(file name).exe': Loaded 'C:\Windows\System32\KernelBase.dll', Cannot find or open the PDB file
'(file name).exe': Loaded 'C:\Windows\System32\imagehlp.dll', Cannot find or open the PDB file
'(file name).exe': Loaded 'C:\Windows\System32\msvcrt.dll', Cannot find or open the PDB file

The program '[3828] (file name).exe: Native' has exited with code 0 (0x0)."

The page before I write down a similar output but the problem of "
'(file name).exe': Loaded 'C:\Windows\System32\dbghelp.dll', Cannot find or open the PDB file
(file name)exe has triggered a breakpoint" is completely disappeared. Interesting...

[Arjen_Markus]

This may look disturbing but there is nothing the matter - this is just a consequence of the
debugger telling you more things than you probably want to know ;).

If you run the program outside theVisual Studio environment, you will not see anything
of the kind.

Regards,

Arjen