- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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)
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...
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...
Link Copied
27 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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:
I cannot understand why it does not run properly...I was running the project which was fine on CVF.
"(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 breakpointThe 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
Have you determined that the array bounds error is incorrect?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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....
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....
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
In such circumstances, it is incorrect to blame the failures upon the compilers.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Lorri, should I change it to /check:unbounds ? If so, how ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@ 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.
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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).
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).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Best regards J_Clausen
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@ 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":
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...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
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
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page