In Debug mode Watch doesn't display proper values

[Amalia_B_]

I believe I've seen other posts with this problem, but this is aggravating as it makes the Debugger somewhat useless while tracing through a program.  While in Debug mode and stepping through execution lines, all local variables, whether I specify them in the Watch window, or mouse over them in the code, the debugger doesn't display the proper values.  I believe internally, variables are being correctly computed as the program wouldn't work otherwise, but the variables [when viewing at a breakpoint] are extremely large or extremely small, as if uninitialized.

My compiler options:

/nologo /debug:full /Od /Qdiag-enable:sc-include /debug-parameters:all /warn:declarations /warn:unused /warn:ignore_loc /warn:uncalled /warn:nousage /warn:interfaces /Qcomplex_limited_range /Qfp-stack-check /module:"Debug\\" /object:"Debug\\" /Fd"Debug\vc100.pdb" /traceback /check:pointer /check:bounds /check:uninit /check:format /check:output_conversion /check:arg_temp_created /check:stack /libs:qwin /dbglibs /c

Is this a known bug?

Amalia

[Anonymous66]

Hi Amalia, This shouldn't be caused by the options you are using. Can you attach a copy of a program that reproduces the debug problems so I can investigate the issue? Thanks, Annalee Intel Developer Support

[DavidWhite]

I am also having similar problems. When I enter a subroutine in debug mode, all the INTENT(IN) variables are correct. The INTENT(OUT) variables are calculated correctly, but on returning to the calling routine, the values are wrong. This is using XE2013 for ia32. All of the variables are Real(KIND=8). Like the original poster, I believe the program is doing the correct calculations, but the Watch window is displaying the wrong values. My program is too large and is difficult to post, as it is has runtime user security, and is a DLL called from Excel via VBA. It appears that I will have to revert to adding multiple debug writes to file to solve my other runtime problems, as the debugger is essentially useless at present. Thanks, David White

[TommyCee]

I've seen sort of a related "problem". I restructured some F77 code that used many COMMON blocks for passing variables. The F90 code features a Module for holding declarations of variables that were once contained in COMMON blocks. The good news is that, via 'use ModuleName', all subunits have appropriate access to variables and their values. The bad news is that - by setting local watches - I now can't "see" the variable values in subunits when I try to do debug tracing. This capability is forfeited w/ the Module structure. I wish IntelVF had some sort of magic compiler switch that would allow the local unit tracing under the configuration I describe.

[Amalia_B_]

Annalee, My program is rather large and I haven't been able to come up with a suitable small test program to illustrate the problem. I've seen many other posts on the forum regarding this problem with the Debugger. Has Intel been able to track it down and are they planning a patch for this soon?

[Anonymous66]

Amalia, Some similar issues have been reported, including one we are planning to fix in the next update. Without seeing your program though, it is impossible ot know if you are seeing the same problem or an unknown issue with the watch window. David, Intent(out) variables become undefined if their value is not set within the procedure. Is that what you are seeing or is the variable not showing a value you set it to within the procedure?

[Anonymous66]

TommyCee, You can watch module variables by adding them to the watch window as module_name::variable_name where module name is the name of the module it is contained in and variable_name is the variable being watched.

[DavidWhite]

Annalee, what I am seeing is the Intent (OUT) variables are undefined on entry (expected), set to their correct values in the subroutine (expected), but apparently undefined or getting wrong address after exit (not expected). I suspect in run mode, the variables are correct, but in debug mode, I am unable to confirm this through the watch window. Thanks, David

[Anonymous66]

David, Do you have a sample program where this occurs? I am not seeing this behavior with simple test cases. Thanks, Annalee

[DavidWhite]

Annalee, I have not attempted to set up a simple test case, as I mentioned before, this was part of an app called from Excel. However, I reinstalled XE 2011 Update 11 this morning, and this does not show this behaviour. Upon exiting the subroutine, all of the variables in the caller are correct. So this problem is unique to XE 2013. I'll see what I can do about a test case. Regards, David

[DavidWhite]

Annalee, Here is a simple partial set of my code, with the proprietary calcs removed. It fails under XE 2013, but works under XE 2011. You may need to make sure the Excel Add-In is loaded properly so that the call to the DLL works. The results in BayerComponents are correct before the return to the main routine, but all the values, esp FreeNaOHgpL, NaAluminategpL and CONC(), change under XE 2013.

[Anonymous66]

Hello David, I am transferring this thread to the Debug Solutions User Forum since it is purely about debugging. Someone from that forum will get back to you shortly. Annalee

[DavidWhite]

Is this problem going to be picked up and submitted as an issue to be solved or is transferring it to the debugging forum a way of forgetting about it! David

[Anonymous57]

The Problem is transferred to get resolved. There are three possible tools (subset) involved. The compiler (i.e. the generated debug information), the debugger itself - this is less likely as the differences occur after installing the v13.0 FORTRAN tool [with the same VS2010]. Finally we have an extension to the debugger - Fortran Expression Evaluator - which may be involved. We have already submitted one defect related to FORTRAN variables in debugger watch window. Need to investigate if this is the same issue or a new problem Bernth

[gianni_c_]

This debugger problem has already been mentionned and has been somewhat overlooked by the developpers... See for instance: http://software.intel.com/en-us/forums/topic/327633 As a result, how can someone get use of the new compilers if the debug is flawed? Looking forward to getting a xe 2013 update release!

[Anonymous66]

Our debug developers are planning to include a fix for this issue in the next update which is scheduled for later this month. Regards, Annalee Intel Developer Support

[DavidWhite]

Thanks, Annalee. Any idea when the debugger update will rollout into the Visual Fortran releases? This problem has been a showstopper as far as using XE 2013 is concerned. Thanks, David

[Anonymous66]

Hello David, This update has been released. Regards, Annalee

[DavidWhite]

Annalee, Update 1 does not solve the problem detailed in the test solution I uploaded earlier. When returning from my subroutine, all of the arguments have different values after the return compared to the same variables within the subroutine. As I said before, this is a show stopper for debugging programs using IVF 2013. Thank you, David

[Anonymous57]

Hello David, We have done the following simplified tests. A main routine was added invoking BayerDensity() with some simple values. With this set-up we could reproduce the problem reported with the 13.0 compiler. The values mentioned did all changed upon return from BayerComponents(). This matches the description of the problem. With the same set-up we cannot reproduce the problem with 13.0 Update 1 compiler. Hence we need further details to reproduce the issue with the latest compiler version. Did we miss something in the simplified test? Best Regards, Bernth

[DavidWhite]

Bernth, Except that I was calling BayerDensity from Excel via the wrapper routine BayerDensity_F, in principle, what you are doing is equivalent. I will check again on my work computer and get back to you. Thanks, David