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]

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

linker command line options:
/OUT:"$(OUTDIR)/WriteTest.exe" /INCREMENTAL:NO /NOLOGO /DEBUG /PDB:"$(OUTDIR)/WriteTest.pdb" /SUBSYSTEM:CONSOLE

[ferrad]

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.

Adrian

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

[jim_dempsey]

/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

[kenneth_l_fowler]

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

or

if ( a == 1 ) then

b = 2

end if

Thought you should know.

[ferrad]

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.

Adrian

[hansr]

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.

Hans

[Steven_L_Intel1]

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.

[ferrad]

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

Adrian

[Steven_L_Intel1]

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

[kenneth_l_fowler]

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

[Steven_L_Intel1]

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.

[jim_dempsey]

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

[ferrad]

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.

Adrian

[Steven_L_Intel1]

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.

[Dobrivoje_N_]

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.

Dobrivoje

[ferrad]

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