Debugger loses synchronization with editor output?

Debugger loses synchronization with editor output?

Hi folks, I've got a strange one here:

I'm using Win7/VC++ 2008/ Intel C++ compiler 11 plug-in.

I have a project that was working correctly. It runs well, produces the correct output and I can debug it if need be. I thought I'd make some modifications to the class layout and - being cautious - copied the whole project into another folder and started modifying this duplicate version. When I tried to run in debug mode and stop at a breakpoint, to my astonishment the debugger stopped in a function that I wasn't calling. I double-checked that I was indeed building in debug mode and tried again...same behavior. After fussing for an hour or so (which included several restarts of both the computer and VS 2008) I decided to go back to the original unmodified project that was working properly and try that again. Incredibly, this one now behaves the same when debugging even though on Friday everything was working normally and it hadn't been modified since then (other than being copied). When I run the debug version without actually trying to debug it i.e. no breakpoints, etc it runs all the way through and generates the correct output as usual. When trying to run to a breakpoint or the cursor, it stops in sections of the code that it shouldn't be in in the first place and starts hopping around, landing on blank lines, etc. After a lot of head-scratching - > swearing, I've noticed the following pattern which implies there's some sort of graphical error in what is being shown in my code editor window when trying to debug. Consider two functions in my source code, arranged one above the other:

void Func1(int x)

{

if(x == 0) // <- Put a breakpoint at this conditional statement. At runtime this evaluates to false and it will test the next condition.

{

.

.

}

else if(x == 1)

{

.

.

}

}

void Func2(int y)

{

// Some general code, completely unrelated to the code above.

.

.

. // <- When debugging, debugger stops here (call it "line x") even though this code/function is never invoked!

.

.

.

.

. // <- It then jumps here, as though it were executing the "if-else" block in the above function, which I believe it is since it runs fine.

.

}

It seems like the code block being shown in the code editor while I'm trying to step through under the debugger is not the code block that is actually being interrogated by the debugger. This explains the crazy behavior as I try to step through line by line. One other note...if I try to interrogate the value of a variable by hovering the mouse cursor over it, I get nothing. If I add the variable to the watch window I get an error in the watch window warning me the variable is not in the stack frame, or something like that. Has anyone else seen this? Is my project somehow schmutzed-up and, if so, is there a way to force a total "regeneration" to try and get things back to normal? Thanks in advance!

22 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Out of desperation I'm trying to revert to the Microsoft compiler to salvage my project. When I choose "Project -> Intel C++ Pro -> Use Microsoft C++" and rebuild all, I get 100 errors of the type:"error C2719: 'm1': formal parameter with __declspec(align('32')) won't be aligned" in the Intel file "immintrin.h"How do I resolve this error? Thank you.

It makes me wonder if any Windows update during the weekend caused such problem.

Please read this KB - http://software.intel.com/en-us/articles/debugger-console-windows-do-not-close-when-exiting-debugger-and-visual-studio/
The symptom is different though.

Jennifer

"error C2719: 'm1': formal parameter with __declspec(align('32')) won't be aligned" in the Intel file "immintrin.h"

It's because the include-dir list have the icl-include in front of vc-include. When building with vc, you need the immintrin.h from vc-include.

Jennifer

Hi Jennifer,I'm sorry but I don't understand your instructions. Can be more specific? Thank you.

Try following:
1. instead of set the compiler to VC from project property dialog; use menu "Project -> Intel C++ Compiler -> Use Visual C++" to set the project or solution to use VC
2. but above may not solve the compile-error problem if you have specified the IntelC-include in the project property or the tools -> option -> project & solutions -> VC build directories. Otherwise the step #1 should solve the compile-time error.

Jennifer

Here's what I currently have in "Tools -> Projects and Solutions -> VC++ Directories" list:$(VCInstallDir)include$(VCInstallDir)atlmfc\include$(WindowsSdkDir\include$(FrameworkSdkDir)includeD:\RSI\IDL63\externalC:\Program Files (x86)\Intel\Compiler\11.1\038\lib\ia32C:\Program Files (x86)\Intel\Compiler\11.1\038\ipp\ia32\includeI have specified the VC compiler using "Project-> Intel C++ -> etc" as you state. This generates the compiler errors I'm getting. I've tried removing "C:\Program Files (x86)\Intel\Compiler\11.1\038\lib\ia32" in the above list and recompiling but I'm getting the same series of errors.

sorry,my bad. this is AVX intrinsicsheader. you need to use it with icl together.

were you able to build with VC before?

Jennifer

Yes, actually this happened to me before back in November of last year I believe. Everything was working well and then for no apparent reason the debugger started behaving as it is now. I even have a post on this forum about it. Anyway, my "solution" back then was to revert to the Microsoft compiler and rebuild everything, then go back to the Intel compiler. For some reason now I'm having trouble compiling with the microsoft compiler.The Intel compiler is compiling the code properly as I can run it...it's just that I can't debug it. I thought maybe the debug database file had become corrupt, so I deleted the contents of the Debug folder and rebuilt all but this had no effect on the crazy debugger behaviorr.I'm also linking to IPP if that makes any difference, and in a few of my files I have "#include "xmmintrin.h" if that is of anyrelevance. Any ideas? Strange to be getting all these errors in Intel files.-L

can you search your code to see how "immintrin.h" is included? and check this file's compile option (properties to see if it has /I option to include IntelC's include dir).

The "xmmintrin.h" is also offered by VC as well. In order to use the "xmmintrin.h", you need to add "/I C:\Program Files (x86)\Intel\Compiler\11.1\065\include\ia32".

(**** Are you still using 11.1.038 pkg? if so, please upgrade to 11.1.065 (update 6). There is a bug in 11.1.038 that may cause programs to hang on Windows 7 - http://software.intel.com/en-us/articles/program-crashes-or-hangs-on-some-systems/. )

Jennifer

Hi Jennifer,I do not directly reference "immintrin.h" anywhere in my code. The only intrinsics I'm including are "xmmintrin.h" and "emmintrin.h". I've added the path to the Intel compiler include folder, so here's what I have in "Tools -> Options -> VC++ Directoried -> Include files" list box:$(VCInstallDir)include$(VCInstallDir)atlmfc\include$(WindowsSdkDir)\include$(FrameworkSDKDir)includeD:\RSI\IDL63\externalC:\Program Files (x86)\Intel\Compiler\11.1\038\ipp\ia32\includeC:\Program Files (x86)\Intel\Compiler\11.1\038\include\ia32There is no change in the behavior, I still get the compiler errors in the immintrin.h file. I'm very hesitant to update my install until this issue is resolved. I don't believe this is related to the bug you mention.

Yes, let's find out why the code doesn't compile with VC.

On the file that you get the compilation error about "immintrin.h", please turn-on "Show Includes" under the file's property -> C/C++ -> Advanced. Then "Compile" this file, in theoutput window, you'll see a list of .h files including the full path.

Check where the "emmintrin.h" and "xmmintrin.h" are coming from. It should display the "immintrin.h" with a full path as well.

From the output, you might be able to figure out why the .h are coming from those different dir. Or you can save the output to a txt file, and attach to your response.

Thanks,
Jennifer

Hi Jennifer, there seems to be some confusion. I'm not actually getting an "immintrin.h" compilation error in one of my files, I'm getting a compilation error in the "immintrin.h" file itself. Here's the error message:Error 4 error C2719: 'm1': formal parameter with __declspec(align('32')) won't be aligned c:\program files (x86)\intel\compiler\11.1\038\include\immintrin.h 82

Yes, I know.

But still, try the "Show Include" for the file that you get the error C2719, and send me the buildlog.htm.

Jennifer

Okay Jennifer, please see attached build log. Thanks.-L

Attachments: 

AttachmentSize
Downloadtext/html BuildLog.htm0 bytes

I just reconstructed the entire project/solution by hand and I am still receiving the same compiler errors with the Microsoft compiler. I then switched to the Intel compiler (using the default settings) which failed to compile..something about an argument being too large? Below is the output window text:

1>------ Rebuild All started: Project: CosiCorrDll, Configuration: Release Win32 ------1>Deleting intermediate files and output files for project 'CosiCorrDll', configuration 'Release|Win32'.1>Compiling with Intel C++ 11.1.038 [IA-32]... (Intel C++ Environment)1>Intel C++ Compiler Professional for applications running on IA-32, Version 11.1 Build 20090624 Package ID: w_cproc_p_11.1.0381>Copyright (C) 1985-2009 Intel Corporation. All rights reserved.1>icl /c /O2 /Oi /Qipo /I D:\RSI\IDL63\external /Iicl: error #10032: argument is too long: 'C:\Program Files (x86)\Intel\Compiler\11.1\038\IPP\ia32\Include;C:\Program Files (x86)\Intel\Compiler\11.1\038\include" /D WIN32 /D NDEBUG /D _WINDOWS /D _USRDLL /D COSICORRDLL_EXPORTS /D _WINDLL /D _UNICODE /D UNICODE /EHsc /MD /GS /Gy /fp:fast /FoRelease/ /W3 /nologo /Zi /Qvc9 /Qlocation,link,D:\Program'1>Build log was saved at "file://C:\CosiCorrDll\CosiCorrDll\Release\BuildLog.htm"1>CosiCorrDll - 0 error(s), 0 warning(s)========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========1>------ Rebuild All started: Project: CosiCorrDll, Configuration: Release Win32 ------1>Deleting intermediate files and output files for project 'CosiCorrDll', configuration 'Release|Win32'.1>Compiling with Intel C++ 11.1.038 [IA-32]... (Intel C++ Environment)1>Intel C++ Compiler Professional for applications running on IA-32, Version 11.1 Build 20090624 Package ID: w_cproc_p_11.1.0381>Copyright (C) 1985-2009 Intel Corporation. All rights reserved.1>icl /c /O2 /Oi /Qipo /I D:\RSI\IDL63\external /Iicl: error #10032: argument is too long: 'C:\Program Files (x86)\Intel\Compiler\11.1\038\IPP\ia32\Include;C:\Program Files (x86)\Intel\Compiler\11.1\038\include" /D WIN32 /D NDEBUG /D _WINDOWS /D _USRDLL /D COSICORRDLL_EXPORTS /D _WINDLL /D _UNICODE /D UNICODE /EHsc /MD /GS /Gy /fp:fast /FoRelease/ /W3 /nologo /Zi /Qvc9 /Qlocation,link,D:\Program'1>Build log was saved at "file://C:\CosiCorrDll\CosiCorrDll\Release\BuildLog.htm"1>CosiCorrDll - 0 error(s), 0 warning(s)========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========

The buildlog does help.

1. to build with "CL", either under the file's property or project property, there are "Additional include directories" set as "C:\Program Files (x86)\Intel\Compiler\11.1\038\IPP\ia32\Include;C:\Program Files (x86)\Intel\Compiler\11.1\038\include". You need to remove it.

If your code use IPP, you can keep the IPP include dir, but remove the IntelC include dir.

2. About the "error #10032: argument is too long....", it seems the IDE integration does know how to pass the above concatenated directories. You just need to use "edit" to add multiple include dirs and then it should work. like the screen capture below:

Let me know how it goes.

Thanks,
Jennifer

Thanks for the help so far Jennifer...but I don't understand what you mean by " To build with 'CL' ". What is "CL"?

My bad, I shouldn't use capital. I mean "cl.exe" (Visual C++ compiler).

Jennifer

Okay, it's almost back to normal. I've managed to get the project to compile and link with Intel C++. The debugging behavior is much improved i.e. I can stop at a breakpoint, step through the code, etc with two exceptions:1) There is one function in my class wherein any breakpoint is not observed by the debugger. I can set breakpoints anywhere in the class and they will trigger properly except a breakpoint placed in this one function.2) The incremental linking never seems to work (it was working before). When I try to compile and link now I always get:"LINK : C:\MyDll\Debug\MyDll.dll not found or not built by the last incremental link; performing full link"Any ideas what might be causing this?

Are you using a debug build or a release build? My experience is that aggressive optimizations (/Qipo, /O3 or /Ox etc.) can cause the debugger to jump back and forth at least between lines within a function - but due to optimizations I could imagine that jumping between functions is also possible. So is missing breakpoints.

This is the first thing I checked. I'm using the debug build.I believe this problem had something to do with moving files around. Before making any large change, I usually make a copy of the solution and put it in another folder, for exampe:Original:C:\MySolution\MySolution\...source files...Temp copy for experiment:C:\MySolution experiment\MySolution\...source files...This usually poses no problem, but somehow something failed to "hook-up" with the new folder (that's my theory anyway). I eventually got things back to normal by starting a new solution from scratch, adding new source and header files through the solution explorer window, and copying/pasting the code text from the old project into the new files. It was tedious but it seems to have worked. The only issue now is the lack of any incremental linking capability.So...no more moving around files for me!

Leave a Comment

Please sign in to add a comment. Not a member? Join today