Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Beginner
5 Views

Visibility of variable to debugger inside a for loop scope

Hello!

I'm new to Intel C++ compiler (9.1) and I'm facing a hard to work around problem: in the code (written in the past by others than me), all variables defined inside the scope of a for loop are invisible (cannot set watches) in debug config. I'm executing the code line by line but all these variables cannot be evaluated. I get a CXX0017 error.My app is in x64 but all optimization is disabled. I think so...

Any idea would be more than appreciated!

Setup:

VS 2005 + ICC 9.1, Debug config... I will give more info if I have to.

Dominique
0 Kudos
14 Replies
Highlighted
Moderator
5 Views

This is a similar issue reported about debug info with omp. It is fixed in our next major release 12.0 and next version of Intel Parallel Composer.

Please wait for the news when the new compilers are released.

Thanks,
Jennifer
0 Kudos
Highlighted
Beginner
5 Views

This is a similar issue reported about debug info with omp. It is fixed in our next major release 12.0 and next version of Intel Parallel Composer.

Please wait for the news when the new compilers are released.

Thanks,
Jennifer

Jennifer,

You mean even if omp is disabled? (OpenMP support is set to NO in Properties-C/C++-Language-OpenMP support)

By the way, why am I able to see these variables when I start/build/debug a little test application like this one?

int main(...)
{
for( int i=0; i<20; i++ )
{
cout << i << endl;
}

return 0;
}

The "i" is perfectly visible during debugging while it is invisible using the same compiler/debugger in my main application.

You sais the bug will be fixed in 12.0 but I see no bug with my little app... Where should I look for the difference that make my main app essentially undebuggable? Any hints?

Thanks a lot!

Dominique
0 Kudos
Highlighted
Moderator
5 Views

Sorry about the omp assumption. For simple C program it should work.

Another suggestion is for you to try the 11.1 eval. could you do that?

Jennifer

0 Kudos
Highlighted
New Contributor II
5 Views

Nothing more to add, though could be more careful during debugging.

Usually, in a large application involving many modules & files, which is usually production and release build, while debugging, we only set /Od for the files we think will showcase the error and the local variables.

In that case only, I have found that the variables in the files that missed /Zi (debug symbols) do not get shown. This can be also (but not exclusively) due to that in Visual Studio project, you have /Zi , /Z7 etc or /Od set in project-level, while the file-level settings may over-ride the project settings.
Apart from this, there are situations Ithink, which you may try, when the linker options need to set the /debug or /pdb set of options in the project, so as to ensure they are seen in Watch or correct symbol information is generated.

The errorCXX0017 error is a Visual C++ project error usually, and you may need to check the following which I came across:--
///////////////////////////////////////////////////////

A symbol specified in an expression could not be found.

One possible cause of this error is a case mismatch in the symbol name. Because C and C++ are case-sensitive languages, a symbol name must be given in the exact case in which it is defined in the source.

This error can occur when trying to typecast a variable in order to watch the variable during debugging. The typedef declares a new name for a type, but it does not define a new type. The typecast attempted in the debugger requires the name of a defined type.

Tips

Make sure the symbol is already declared at the point in the program where it is being used.

Use an actual type name to cast variables in the debugger, rather than a typedef-defined name.
//////////////////////////////////////////////////////

There may be more than 1 factor you may need to look into, as the simple test application at your end is not failing to debug with local variables, so it seems to be project-setting related problems as stated above, or mismatches in symbol name .

0 Kudos
Highlighted
Beginner
5 Views

Nothing more to add, though could be more careful during debugging.

Usually, in a large application involving many modules & files, which is usually production and release build, while debugging, we only set /Od for the files we think will showcase the error and the local variables.

In that case only, I have found that the variables in the files that missed /Zi (debug symbols) do not get shown. This can be also (but not exclusively) due to that in Visual Studio project, you have /Zi , /Z7 etc or /Od set in project-level, while the file-level settings may over-ride the project settings.
Apart from this, there are situations Ithink, which you may try, when the linker options need to set the /debug or /pdb set of options in the project, so as to ensure they are seen in Watch or correct symbol information is generated.

The errorCXX0017 error is a Visual C++ project error usually, and you may need to check the following which I came across:--
///////////////////////////////////////////////////////

A symbol specified in an expression could not be found.

One possible cause of this error is a case mismatch in the symbol name. Because C and C++ are case-sensitive languages, a symbol name must be given in the exact case in which it is defined in the source.

This error can occur when trying to typecast a variable in order to watch the variable during debugging. The typedef declares a new name for a type, but it does not define a new type. The typecast attempted in the debugger requires the name of a defined type.

Tips

Make sure the symbol is already declared at the point in the program where it is being used.

Use an actual type name to cast variables in the debugger, rather than a typedef-defined name.
//////////////////////////////////////////////////////

There may be more than 1 factor you may need to look into, as the simple test application at your end is not failing to debug with local variables, so it seems to be project-setting related problems as stated above, or mismatches in symbol name .

Hello again!

Most of the time, when I want to set a watch, a drag-and-drop the variable into the watch window. So, no mispeling. Also, I found that even "int i" is invisible. int is not a typedef.

For my project, /Od and /ZI are set. But I tried /Zi and /Z7 too. No change.

What is funny (if the word funny can be used here) is that somewhere the variables are visible inside a for-loop, and somewhere else they are not.

I'm working with VS for more than 12 years but I use Intel Compiler for 3 months only and it is the first time I have to deal with this problem.

I'll try some things but I found that the best way is to declare the variables outside the loop (outside its scope{}). Tedious job and beleive me, I'm not happy about that. But we will probably switch to a most recent version than 9.1 in few months from now. I hope the bug is going to be fixed.

By the way, my project is a "pure C++" project that I attach to a GUI programmed in .NET. I don't know if this can be the source of the problem. Any way, in few locations (in the code) the variables are visible inside the for scope...

I'll will consider the person that will tell me "just add the /Dothejob switch" as a guru.... ;-))

Dominique
0 Kudos
Highlighted
5 Views

?? webmaster ??
When replying to this, the original post appears as dual columns ???


My reply,

In Visual Studio you have an option to display local variables (similar to auto). You might experiment with turning on AND off local and auto. When auto is enabled, sometimes some of the variables in scope will toggle on and off.

Jim Dempsey
0 Kudos
Highlighted
Beginner
5 Views

?? webmaster ??
When replying to this, the original post appears as dual columns ???


My reply,

In Visual Studio you have an option to display local variables (similar to auto). You might experiment with turning on AND off local and auto. When auto is enabled, sometimes some of the variables in scope will toggle on and off.

Jim Dempsey

Jim,

I searched for it... could you tell me where I can find this option?

Thanks,

Dominique

0 Kudos
Highlighted
New Contributor II
5 Views

On the Debug menu, choose Windows, then choose the name of the variable window you want to display (Autos, Locals, Watch, or Watch1 through Watch4).

I believe the reason you are not able to locate the menu option is :-- You cannot access these menu items or display these windows in design mode. To display these menu items, the debugger must be running or in break mode.

Please try it and check for Locals & Auto windows too..

Also, if possible and feasible for you, try using Windbg , windows debugger for debugging in that part of application, it offers more extensive set of debugging options, the command-line options (like dt , dv for display type, display variable etc if you search in Windbg tutorial) , unlike Visual Studio debugger which only provides Windows to look at variables etc. So, might be, the command-line commands (display variable, dv) in Windbg may give you headroom for watching variables, plus you can watch the,m in Locals or Watch window as in Visual Studio .

0 Kudos
Highlighted
Beginner
5 Views

I am having the same problem with Intel Parallel Studio 2011 in Visual Studio 2010. Once the debugger steps into a while or for loop I can no longer watch any values (which will also cause break conditions not to work). It happens with every single C++ project I create in which I use Intel C++ as compiler. If I recall correctly, it also occurred with the previous version of IPS in Visual Studio 2005.

Another issue I get is that STL containers storing objects show "error" instead of their value in many cases. The number of items is correctly displayed, though. That means that if an STL container (like vector or deque) has 10 items, I will see "error" 10 times.structs and built-in types seem to work just fine. I have no idea if both problems are somehow related.

Those are indeed quite serious issues which heavily hurt development. My current workaround is to debug in disassemble mode, and it is not nice. For the STL problem the only workaround would be to know the internal structure of the container, and it is not nice either.

Have you made any progress on the issue?

Thanks,

Paul.

0 Kudos
Highlighted
Beginner
5 Views

It seems the problem in Visual Studio 2010 is actually not Intel C++'s fault. The issue is reported athttps://connect.microsoft.com/VisualStudio/feedback/details/612260/no-debug-info-for-local-variables..., and they say it has been fixed already in their code base.
0 Kudos
Highlighted
Beginner
5 Views

Although Visual Studio seems to have a known issue, using Intel C++ triggers the issue way more easily. I have tried recompiling files that have this problem with Visual C++, and I can debug them just fine. If I switch that file back to use Intel C++, the problem strikes back and makes debugging a complete nightmare.


Could anyone at Intel confirm this issue?
0 Kudos
Highlighted
Moderator
5 Views

Thanks to binksoftware for submitting a testcase that duplicates the debug issue. I'll file a bug report to the compiler.

Please stay tuned and I'll let you know when it's fixed.

Thanks all for yourpatience!
Jennifer

0 Kudos
Highlighted
Beginner
5 Views

Hi.
Are there any updates regarding this issue and alsoDPD200164055?
I had to run the debugger again recently with code compiled with the Intel C++ compiler included in Intel Composer XE 2011, and it is still the same: undebuggable in anything other than pure assembler.
Thanks.
0 Kudos
Highlighted
Moderator
5 Views

This specific bug DPD200164055 is fixed in update 3. It's just got released several days ago.
Please download the update 3 from the link below.

Thanks
Jennifer
0 Kudos