Another case where the debugger does not stop on an error

Another case where the debugger does not stop on an error

Now I get an internal formatted write run-time error (see attached). However after clicking OK it carries on running. How do I get it to stop at the piece of code responsible for this error? Hitting the break (||) button gives my useless Call Stack again.

37 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

You may be able to find this one. (bedause the program successfuly continues)

The debugger has an option to "Step Out" of the subroutine. This is a button on the toolbar (or one you can add to the toolbar) that looks like tiny lines of text with an arrow comming out. As you click on that the debugger will step out each level until it comes back to your fortran code.

Your attachment did not make it into the forum.

Jim Dempsey

I tried that before posting, unfortunately thestack information is useless (to me) and stepping out just jumps from one bit of disassembly to another and then to C++. See attached jpg's. No Fortran information anywhere.


What this looks like is that your program has multiple threads. The call stack that you are seeing is the stack of one of the threads (the one calling GetMsg) and a second thread(the Fortran code) produced the pop-up with the ifort error.

When you enter the break point by pressing the || (break all) then the active thread could be any one of the threads of your application. To switch to the F90 code thread

Debug | Windows | Threads

Then you will have to identify the thread that is the F90 thread of interest (typicaly MAIN$...$...)

Jim Dempsey

Nope, tried that too... see attached. The Win32 Thread's are all windows systems calls, the other one is similar to what I posted previously. No Fortran in sight.

Adrian (not Ferrad),

Then it looks as if the Fortran thread has terminated while the message (dialog) thread has not.

In a few posts back your screenshot of message box for the F90 showed an error regarding formatting for a write. My experience on this says this indicates passing unititialized variables into the WRITE statement.

You can use a variation on the #define we used to catch the WRITE errors.


#define WRITE(io,fm) write(ioUchk(io),fm)

function ioUchk(io)
    integer :: ioUchk, io
    if(io .le. 0) then
        stop ! set break point here
    ioUchk = io
end function ioUchk

    program WriteTest

    WRITE(6,*) "test"

    end program WriteTest

Compile with preprocessor

Note, the macro will not work with WRITE(*,*)...

Jim Dempsey


This looks like just what I need, however I can't get this example to break in the iochk(io) function.

Also, although this example compiles just fine, when I put the #define and function in one of my files, I get compilation errors (I compile with /fpp):

D:sfpintelbugsds_place2error_handler.for(106) : Error: Syntax error, found POUND_BASE '' when expecting one of: T> ; BLOCK BLOCKDATA PROGRAM TYPE COMPLEX BYTE CHARACTER ...
#define WRITE(io,fm) write(ioUchk(io),fm)
D:sfpintelbugsds_place2error_handler.for(106) : Error: Syntax error, found ')' when expecting one of: . ( , %
#define WRITE(io,fm) write(ioUchk(io),fm)
D:sfpintelbugsds_place2error_handler.for(106) : Error: Syntax error, found END-OF-STATEMENT when expecting one of: . , %
#define WRITE(io,fm) write(ioUchk(io),fm)
compilation aborted for D:sfpintelbugsds_place2error_handler.for (code 1)

Ignore the first part my previous post - I can get it to stop in the ioUchk function. But I still get the compilation errors in my file.

Adrian (ferrad)

The fpp #define and other #keywords must start on column 1.


A lot of my write statements have three arguments, eg.
WhileI could have another write definition to take three arguments, that would mean I would have to change the 'write' portion of all the references to the new 3 arg function. Is there any way to have both the 2 and 3 arg version reference the same function using optional args?

I did those manually. However I'm getting a strange behavior with fpp in this case:

#define write(io,fm) write(ioUchk(io),fm)
#define Write(io,fm,er) write(ioUchk(io),fm,er)
Write(out_file,1010,err=9999) j,

gets translated by fpp into:

write(ioUchk(ioUchk(out_file)),1010) j,

Any idea why the three parameter version gets confused?


Must be something to do with write on both sides of the define. The follwoing works:

#define write(io,fm) WRITE(ioUchk(io),fm)
#define Write(io,fm,er) WRITE(ioUchk(io),fm,er)


Well, after hunting down all write statements connected to a unit, and failing to find one that supplied a -5, I decided to read the error message more closely: It says output conversion error, unit -5, file Internal Formatted Write, which of course is writing to a character variable, not a unit!
So there is obviously a problem with one of my write(message,...) statements.
Still hunting,

The default for fpp defined macros is case sensitive.

So Write and write were two different macros.In your pre-fix statement your second macro declaration referenced the first macro declaration.

In the code sample sent to you the execution portion use WRITE


Here is a hint.

Write a simple test program (maybe you can do this in one line) where the write statement produces the same error as you are observing. Then with the debugger, on the simple program, place a breakpoint on the write. On break, open a dissassembly window. Step in to the assembler calls until you see some routine name who's name appears to be the one that is dispatched on the format error. Now that you have the routine name. Start your application. Open a dissassembly window then do the GOTO address to find the entry point of the error routine. If the dissassembly window shows the start of the routing resetting "esp" then place your breakpoint after this instruction (else place at start of subroutine). Run your program and then on break the stack may look better.

Jim Dempsey

Yes, I worked all that out. I eventually found the problem, it was an internal write:

write(message,'(f7.3)') percent

where percent = 1147.939, which obviously cannot fit into f7.3.

I guess my main issue with this investigation is that it's taken me 1 day to find something as trivial as this, whereas the IVF compiler should have simply stopped on the offending line. I feel it is a *really big* problem that the debugger does notstop at the relvant place in the code when an exception is encountered.

The lack of this functionality to me is a show stopper for our company to upgrade to Intel. I cannot expect our developers to perform the same "needle-in-haystack" approach to find and fix these critical code issues. Steve has said they are working on it, but as far as I am concerned the product should not have gone out the door with this major lack of functionality.


I have had no problems with the program stopping on a run-time error. I just tried it now with an internal write. The traceback written to the console window properly identified the line and the debugger stopped, though I did have to use the Call Stack window to work my way back to the frame in my code. It was there.

If you have an example where this does not work, please send a test case to Intel Premier Support.

Retired 12/31/2016

For what it's worth, I have this environment variable set since DVF5 days:

This variable disables the default run-time exception handling, for example, to allow just-in-time debugging. The run-time system exception handler returns EXCEPTION_CONTINUE_SEARCH to the operating system, which looks for other handlers to service the exception.
I know it shouldn't matter when running under debugger, but it doesn't harm either...


Message Edited by JugoslavDujic on 11-15-2005 09:04 AM

If this makes any difference, our product consists of one small executable and many DLL's, C++ and Fortran. The executable calls the C++ GUI, which then calls the Fortran engine code. There are try/catch blocks around the Fortran calls. When the Fortran hits an exception such as those I've listed, it pops up a window (in the internal format write problem), or a traceback (in the array bounds problem), but it seldom stops on the responsible line of code. I say seldom, because it sometimes does, and this appears to be non-reproducible, ie. I can run it once and it won't stop in the right place. Then I make no changes and run it again, and it does.


The formatted write to internal buffer causes a break on my system when the buffer is too small (see message6.jpg). When the buffer is large enough then it writes ******'s into the buffer (see message78.jpg).

and message78

ifort command line options:
/nologo /Zi /Od /fpp /module:"$(INTDIR)/" /object:"$(INTDIR)/" /traceback /check:bounds /libs:static /dbglibs /c

linker command line options:

Maybe it's something to do with (a) being called by C++, or (b) being in a DLL. I have sent the attached example to premier support. It does not stop on the exception in the DLL. So it's not quite the same asthe real world problem, but it's still a problem.


PS. I don't have /traceback, I'll try that.

/traceback aids in producing the line numbers of errors. This may help.

You may also want to add/keep frame pointers (turn off Omit Frame Pointers in Optimizatons)

If the .DLL is producing the error then themust be compiled with/traceback too. If you do not then the traceback on your main program might not yield sufficient information to fix the error. Tentatively you may want to link in the Debug version of the .DLL.

Jim Dempsey

I was going to post something but what Steve said about accessing the Call Stack window From Debug->Windows helped for my problem.

But (a little whine here) I've never had this problem occur when using CVF 6.6. Are there some compiler settings to use that would emulate CVF 6 behavior ?

My Intended Post Read :

When debugging a Fortran console program in IVF 9 how do I prevent the debugger from stopping in routines like output.c or assembly language when certain errors like array bounds problems occur. The debugger doesn't leave me in the source code file and line where the problem occurs and the console output shows only the line number in the main program and not the subroutine and line where the problem occur. Is there a project property I am not setting right ?

I get a window labeled Microsoft Development Environment with an exclamation icon and the words "Unhandled exception at xxxxxxx in xxx.exe: User breakpoint. The window has 3 buttons enabled : Break, Continue, Help . Below I've pasted the test that appears in the console window

forrtl: severe (408): fort: (3): Subscript #1 of the array ASYMPOS has value 0 w

hich is less than the lower bound of 1

Image PC Routine Line Source

ashloads_intel.ex 0085099E Unknown Unknown Unknown

ashloads_intel.ex 0084DBFC Unknown Unknown Unknown

ashloads_intel.ex 007DC13E Unknown Unknown Unknown

ashloads_intel.ex 007DC2FC Unknown Unknown Unknown

ashloads_intel.ex 0071A1D5 Unknown Unknown Unknown

ashloads_intel.ex 00613FAB Unknown Unknown Unknown

ashloads_intel.ex 007A813F _MAIN__ 134 main.f

ashloads_intel.ex 008541B0 Unknown Unknown Unknown

ashloads_intel.ex 0083D02F Unknown Unknown Unknown

kernel32.dll 7C816D4F Unknown Unknown Unknown

a document window for output.c is displayed along with a green triangle indicating the source code line where the access violation is occurring.

Clicking the Break button puts you into the debugging mode. Clicking the Step Out button on the Debugging toolbar brings up a window that says :

There is no source code available for the current location with a checkbox that is unchecked which is labeled "Show disassembly automatically". This window has three buttons : OK , Show Disassembly, and Help. Any of the buttons does nothing for me.

Clicking the Continue button just ends the debugging session

Unhandled exception at 0x7c901230 in xxxxx_intel.exe: User breakpoint.

The thread '_threadstart' (0x9dc) has exited with code 408 (0x198).

The program '[3280] xxx_Intel.exe: Native' has exited with code 408 (0x198

Steve, also I was debugging some code for a Fortran "newbie" who was complaining that certain If-Then statements weren't working.

What didn't work (but was compiled with no errors)

If ( a == 1 ) then b = 2

What does work (obviously)

If ( a == 1 ) b =2


if ( a == 1 ) then

b = 2

end if

Thought you should know.

Great! I'm pleased someone else is having this problem.

I have the unenviable task of being the first develeoper to switch on checking (/check:all) in an mature product, which has been around for >10 years. I have already tracked down 25 array bounds errors, but unfortunately not with the help of the Intel debugger, 25 errors have taken me 6 days to find :(

And all for the same reason as Kenneth above:the debugger does not stop on the line of Fortran responsible for generating the exception, and in most cases it is not even on the call stack.


If it helps: You are not alone! I'm also in that work group spending much time on searching errors, while the debugger stopped in routines like output.c and not at fortran error lines.

A solutionwould behighly appreciated.


Several issues were just fixed in the Fortran RTL that could lead to these behaviors. If you submitted a problem report to Intel Premier Support, we may be able to provide you with an updated library to try. I tried it myself and it worked much better for me.

Retired 12/31/2016

I did submit a case to Premier Support, could I try the new RTL?


I'm waiting to hear back from the engineer in charge. If he says ok, I'll be in touch through Premier Support.

Retired 12/31/2016

Dear Steve,

Thanks for the response. When do you think the improved RTL will be available as an official update ? I realize that is possible that some of the behavior and usage issues are due to hosting IVF inside of Visual Studio, a product that Intel doesn't control. Hopefully Microsoft is responsive to Intel's requests for improvements. And perhaps some of the problems go away with Visual Studio 2005 wheneverIVF works with it. Unfortunately,allof the IVF users have to work with whatwe've got.IVFjust doesn't seem as productive in my opinion as CVF.For example,the checking for unitialized variables in CVF (/warn:unititialized) is done as part of the compilation rather than at runtime (/check:uninit)as done in IVF which is a pain. Catching those problems at compilation lets a user fix them all at once. Having to catch each and every single one of them at runtime is ridiculous. And the popup window that appears in IVF/Visual Studio when an unitilized variable is detected is pretty worthless. When debugging older programs I have to keep CVF around as well as IVF because CVF catches stuff that IVF doesn't (or doesn't easily). But not everyone has CVF in their toolbox.

BTW, I appreciate you hanging around in Fortranland to provide continuity through all of these years and trying to get things fixed for us users. Thought I should provide you an "attaboy" since you get your share of arrows. ;-)

Ken Fowler

I'm uncertain when this fix would appear in an update - a lot depends on when the library team "checks in" the fix. Most likely it will make our late-December update. It is not due to a problem in VS.NET.

Regarding the uninitialized variable checking, the best I can suggest is that you file a Feature Request with Intel Premier Support describing how you would like it to work. These are tracked and used to determine feature lists for future versions.

Retired 12/31/2016

>> not with the help of the Intel debugger <<

I have not experienced your problems using the Visual Studion .NET 2003 Debugger. Maybe your problems have something to do with using the Intel Debugger.

Jim Dempsey

No, I have not used the "Intel Debugger" (didn't know there was one until I saw your post). By Intel Debugger in my previous posts I refer to the debugging of Fortran code under the VS .NET 2003 environment.

It seems to be well behaved for small Fortran apps, but our application is driven from C++, the Fortran is linked in as DLL's. Maybe this has something to do with it.


The debugger in VS.NET works fine for mixed-language applications, including those with DLLs. I have even used it to debug VB.NET/Fortran apps (requires that you enable unmanaged code debugging in the VB.NET project.)

The issue in this thread is not the fault of the debugger at all, but rather the Fortran run-time library which does not provide the correct context when errors are signalled.

Retired 12/31/2016

I've been watching this thread with interest, and I can also confirm this behaviour. In may case, it was a garbaged file name, and the info that lead me to the offending place came from the console output.

However, the catching word for my writing this was "context". Stopping at a brekpoint in a subroutine internal to another subroutine, I only get the local context in the debugger, i.e. the variables that should be visible through host association, are not. Switching the context back to the host, I get the host context, but I lose the local one. CVF did not have a problem with this.

One also wonders why the CVF relict of having to prepend the module variable names in an internal module subprogram (i.e. the construct ModuleName::VarName) in order to have them visible in the debugger has been retained in IVF9.0. As I also wrote in the AV Forum, this effectively precludes analysing these variables by means of the Intel AV.


I have been informed via premier support that this has been fixed and will be in the next release.

Leave a Comment

Please sign in to add a comment. Not a member? Join today