In Debug mode Watch doesn't display proper values

In Debug mode Watch doesn't display proper values

Portrait de amalia.barrios@navy.mil

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

27 posts / 0 nouveau(x)
Dernière contribution
Reportez-vous à notre Notice d'optimisation pour plus d'informations sur les choix et l'optimisation des performances dans les produits logiciels Intel.
Portrait de Annalee (Intel)

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

Portrait de David White

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

Portrait de 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.

Portrait de amalia.barrios@navy.mil

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?

Portrait de Annalee (Intel)

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?

Portrait de Annalee (Intel)

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.

Portrait de David White

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

Portrait de Annalee (Intel)

David,

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

Thanks,
Annalee

Portrait de David White

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

Portrait de David White

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.

Fichiers joints: 

Fichier attachéTaille
Téléchargement testargs.zip87.24 Ko
Portrait de Annalee (Intel)

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

Portrait de David White

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

Portrait de bernth-andersson (Intel)

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

Portrait de 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!

Portrait de Annalee (Intel)

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

Portrait de David White

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

Portrait de Annalee (Intel)

Hello David,

This update has been released.

Regards,
Annalee

Portrait de David White

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

Portrait de bernth-andersson (Intel)

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

Portrait de David White

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

Portrait de David White

Bernth,

I have tried the Excel call and all appears OK with v13.0 Update 1. Today I downloaded and install the full Studio Update 1 package, while last week I had simply updated the Compiler part. I don't know whether that makes any difference. Otherwise, I can only guess that I did not rebuild my DLL properly when I tested it last week. My apologies.

Regards,

David

Portrait de gianni c.

Hi,

This nasty problem strikes again with parallel_studio_xe_2013_update2.

It has disappeared with update1...

Two phenomenom:

> debugger reporting weird values

> and program bugging!

Config:

Visual Studio 2012 + Parallel studio 2013 update 2

Target: Intel C++ Compiler XE 12.1 (v100)

The programs works ok if compiled in debug mode, itr works ok too if compiled in Release using Microsoft Visual Studio.

HELP REQUESTED!

>Thanks

Portrait de Hans Pabst (Intel)

Gianni,

Thank you for the heads-up. Please open a Premier issue with more specific information (alternatively, you can reply with a private message, and attach your code). A reproducer would be very helpful for us, and I would be glad to take your case.

Thank you!

Portrait de gianni c.

Hi Hans -

Please find attached a small test solution that illustrates the issue.

You'll see that although it works properly if compiled in debug mode, its behaviour is completely crazy

in release mode !

gianni

Fichiers joints: 

Fichier attachéTaille
Téléchargement test-intel-2.zip4.82 Mo
Portrait de Georg Zitzlsberger (Intel)

Hello Gianni,

the problem you reported is neither a compiler nor debugger issue. The result is intended.

Rationale:
You used IVDEP pragma which makes the compiler ignore assumed dependencies. This usually has benefits in cases were those assumed dependencies never hold during runtime. The compiler can apply more aggressive optimizations.
In your case, however, assumed dependencies hold, which are accesses to array "hist". There can be multiple loop iterations writing to the same element of that array. With the IVDEP pragma you had indicated the compiler that multiple accesses can not happen, which is wrong.

If you use this pragma (also applies to SIMD pragma) you have to always verify your code. You apparently did so and proved not to use that pragma for your algorithm.

Best regards,

Georg Zitzlsberger

Portrait de gianni c.

Many thanks Georg,

Indeed the Ivdep pragma was definitively wrong!

cheers

gianni

Connectez-vous pour laisser un commentaire.