Another case where the debugger does not stop on an error

[ferrad]

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.

[jim_dempsey]

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

[ferrad]

Jim,

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.

Adrian

[jim_dempsey]

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

[ferrad]

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

[jim_dempsey]

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.

Code:

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

function ioUchk(io)
    integer :: ioUchk, io
    if(io .le. 0) then
        stop ! set break point here
    endif
    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

[ferrad]

Jim,

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)

[ferrad]

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)

[jim_dempsey]

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

Jim

[ferrad]

Jim,

A lot of my write statements have three arguments, eg.

write(file_number,2100,err=9999)

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?

Adrian

[ferrad]

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?

Adrian

[ferrad]

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)

Adrian

[ferrad]

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,
Adrian

[jim_dempsey]

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

Jim

[jim_dempsey]

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

[ferrad]

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.

Adrian

[Steven_L_Intel1]

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.

[Jugoslav_Dujic]

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

FOR_IGNORE_EXCEPTIONS
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...

Jugoslav

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

[ferrad]

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.

Adrian

[jim_dempsey]

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).

[jim_dempsey]

and message78