- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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):
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The fpp #define and other #keywords must start on column 1.
Jim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Adrian
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If you have an example where this does not work, please send a test case to Intel Premier Support.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page