I found a thread of another user on another website with the same problem except he is using Fortran while I am using C++:
https://software.intel.com/en-us/forums/topic/508718
In fact, I can cite her/him:
The problem:
My problem is that in the debug mode the program algorithm works fine except it does not show the values of the variables.
I tried the watch window and also moving mouse over the variable but neither of them works.
I tried very simple codes like Hello World and just defined an integer but the program is unable to show the value of the variable in debug mode.
From time to time the debug mode works correctly. Sometimes I have to restart the debugger 10 times and then it works for 1 time. It does not matter whether I add or remove breakpoints.
My setup:
Windows 7 64 Bit
Visual Studio Ultimate 2013 (from MSDNAA, all original stuff) Version 12.0.30501.00 Update 2.
I have another notebook with Windows 7 64 Bit and the same Visual Studio Version installed -> same problem!
I have the same problem once in a while and the following steps help me solving it:
Make sure optimizations are deactivated in your Debug build. If they are enabled you compiler removes stack frames, puts variable values into cpu registers or inlines whole functions. The debugger does not like optimizations.
Make sure you use a Debug Runtime Library (check 'Runtime Library' in 'Code generation' and select Multithreaded-Debug or Multithreaded-Debug-DLL)
Rebuild your application (right click Project -> "Rebuild"). Sometimes there are problems which can be solved by a rebuild (i.e. when you update source files from repository which are older then your binaries but newer then the source you built the binaries from; or when you update your compiler or libraries and only parts of your application are rebuild).
Disable Minimal Rebuild in 'code generation' option page. It may mess up you program database.
If everything fails you may try to create a clean new project with default settings and add all your existing .cpp/.h files. This way you make sure your settings are not messed up.
If you are using global variables defined within a namespace you always have to enter the namespace into the watch window (i.e. a variable 'x' defined in namespace 'Y' must be watched as 'Y::x')
Use getchar(); at the end of the program or at the end of a cout statement. In my experience, I had to use getchar(); multiple times to show the variables and the solution. Try it!
Related
I'm setting break points in Visual Studio before running the Local Windows Debugger, and they all say this when the debugger is running, with a small warning label on each break point. I can't see why this would be happening; people have talked about using different versions of Visual Studio and getting this error, but I made this project earlier today, pasting the base code from my professor into a new project created on my copy of Visual Studio 2012.
I found this when trying to fix a strange error in my program that wouldn't go away even though I manually fixed things (it was a string error that claimed I was using an index outside the bounds of the string; setting this value to 0 explicitly did not fix it) so I presume that this is the actual culprit.
Make sure you're properly building the code (Build Solution or Rebuild Solution).
In the output panel you should now be able to locate where the binaries are located.
Make sure you're debugging the said binaries by looking in the Debugging page of your project properties, the Command property should most likely be set at $(TargetPath).
Other things to look for. The project should be "Set as startup project", the program database option should be activated (by default). Don't modify the source after you started debugging.
I've a solution with ceratin no: of projects (all of them EXE projects in VC++).
I use VS2013.
This is tied to a version control system (Perforce).
I see that as soon as I start building any of the projects in this particular solution, the VS gets hung.
I see a text "Not Responding" at the top of the VS window.
Howvever teh compilation happens successfully but it takes a very long
time for the compilation due to this hang.
Id the expected compilation duration is "10seconds" it takes 3 mins to compile.
THis problem is seen in both Relaese and debug mode.
A point to note it that the very same projects were building super fast few days back & this issue started few days back.
Evevry other solution and it's projects (except this particular solution projects) are compiling very fast.
Any help is really useful.
You can also try to reset Visual studio settings trough:
Tools > Import and Export settings > reset all settings
this will reset all enviroinment settings, then restart visual studio.
edit:
I would also create a new project and copy/paste header and source files from old project to new one, and then compile.
I am not sure if you are using the P4VS Perforce Plugin with Visual Studio or not. However, there is a possibility that the compile is changing files that are checked into perforce or possibly somehow triggering an update. If you are using P4VS, please try building with it disabled and see if that
builds faster.
Try restarting your computer to see if that works. You may have some memory that was leaked from your program which is making it compile slower than usual. A restart of the computer should free all the memory.
Environment: I have a .NET 4.0 solution that references some Visual C++ projects. Visual Studio 2010.
If I build my solution and run the resulting .exe right from the bin directory, I can reproduce my bug. But if I run it hitting the "play" button in Visual Studio (or if I run the process and attach to it) I can step through the code, and everything works as normal.
For reference, the problem I'm getting is an Access Violation which is most definitely happening the C++ code.
But more broadly, I'm wondering what other reasons there might be that attaching a debugger to a process "fixes" the issue.
MS VS is working like a sandbox. When you are starting app in that sandbox, your program inherits all settings from solution properties (or just VS settings). Make sure, all your options provided for the environment are correct. If that wont solve the problem, please double check those settings and think what can prevent access violation and uncheck/check it.
If you are using external DLL, those from you system and those from IDE may have different version. They, of course, may work in both cases, but also may cause problem like access violation or subcribent out of range, depending what is changed inside those dlls.
If its Windows app, try enabling/disabling LargeAddressAware.
If you are compiling stuff for another machine with different OS, it may happen very often due to changes in memory handling by native OS. Memory can sometimes be multi-blocked, extremely fragmented or even multi-deviced, so compile your program only with compilation especially made for targeted OS/machine
debug mode uses assert() and other stuff directly linked to debugging. If something is wrong in debugging and not in release, it means that it is acceptable by machine but not by debugging insertions. In that case you are screwed but if its not appear to be problem in other debugger, well... problem solved, its debugger issue, espeially if release without debugging options is working.
most tiring method - try to pinpoint access violation address and see inside memory windows to what are you referring.
in other cases, supply us with snippet, so we can tell something more!
#Matt this cant be heap problem, it can happen but its extremely rare.
#Huytard its wont happen, without linked dll's program should't even start.
The correct and short answer. Run Windows Updates.
The correct and long answer.
It turns out my build machine hasn't been updated in a while and was using an outdated version of Visual C++ compiler. There was a bug in the compiler for .NET 4 where static constructors were not getting called first before any other types of constructors (only in Release Mode).
But here's the kicker!
If you run the process in the Visual Studio debugger OR you attach to a remote process. The static constructors DO get called first like they are supposed to! (Hence making the issue completely un-reproducible in a debugging environment -- Even in Release mode) I found the issue by placing message boxes all over the place to determine the code path.
http://connect.microsoft.com/VisualStudio/feedback/details/611716/c-cli-class-static-constructor-not-called-in-release-build
Running the green "play" button will use the IDE's environment
Executing from the directory will use the default environment
My guess is that there are probably some DLL's or dependencies that need to be added (directory paths) to your %PATH% environment variable.
Once you identify the dependencies and double check or something with dependency walker - you can set them in a batch script and then call your application.
For example:
#echo off
set PATH=%PATH%;C:\myLibs
call MyApp.exe
I developed a small c++ program in Visual Studio 2012 on Windows7, 64bit (let's call it PC1). On that pc it runs fine!
Since I didn't have a versioning control system like SVN at hand, I copied ALL the project data (the exact folder structure, DLLs, source files, project files...) to a usb stick and moved it to another computer.
On that other engine there's Visual Studio 2010 on Windows7, 64bit (PC2).
So I just changed the platform toolset to v100 as described here.
I successfully compiled the project on PC2 (clean, build) and wanted to run the exe, but the command prompt stayed empty.
I then tried to debug and added a breakpoint at the very first line of main - which wasn't reached, the command prompt was still empty.
Ok, a usb stick is certainly not the most secure solution for data storage, so I gave it another try and moved it again - the problem remains.
Visual Studio's output on PC2 is the same as on PC1, so I couldn't find any anomalies there.
Yeah, there might be many error sources, so where can I start?
And how can I get a more verbose output for troubleshooting?
Or is this even a common phenomenon (perhaps due to different VS versions) and there's an simple way fix it?
This is not a full solution, but at least I'm a tiny step ahead:
In my last comment I wrote:
I took your advices into account and created a brand new project on PC2, VS2010. I exactly followed this guide: http://frozenhamster.wordpress.com/2011/02/11/lapack-on-windows-with-visual-studion-2010/
That didn't work either, so I removed I "out-commented" everything except for a single cout. Voila, that worked!
But as soon as I make use of the desired Armadillo (LAPACK and BLAS), the project compils but does not run.
What's going wrong here?
I don't get any compiler errors!
I’m porting a C++ sdk from Windows to Mac OSX 10.5. I have a problem in Xcode where my breakpoints in certain files will only be hit if I set them while debugging. If I stop debugging and then restart, the breakpoints no longer get hit. If I add them while not debugging, they don't get hit. This is only in certain files and my breakpoints are always dark blue. i.e. I can’t tell the difference between a breakpoint that will get hit and one that won’t.
Specifically, my sdk is made up of various dynamic libraries. These are built using Perforce jam, which calls the various compile and link executables depending on my OS and compiler version (such as Visual Studio’s cl.exe and link.exe). I have a simple (unit testing) command line application that links to these dynamic libraries and calls code in them. This application on Windows is a Visual Studio project, in which I set breakpoints on library code and expect them to be hit.
I’ve created the same C++ command line utility application in Xcode 3.1.2 that links to the sdk dylibs and calls code in them. Some of the breakpoints work fine. I can set breakpoints in code that’s called from the troublesome code, and step out to the troublesome code, which I can then step through fine. The troublesome code is compiled into the same dylib as code that works fine. It’s also long and complicated enough not to be a candidate for inlining.
I’ve tried the following:
Turn Load symbols lazily off.
Compile with both gcc 4.0 and gcc 4.2.
Do a full clean and shutdown.
Delete the user-specific files of the xcodeproj package.
Rename the files so they can’t clash with system files.
Clear everything out of the Breakpoints window.
Create a new Xcode project.
My application is compiled in debug with DWARF format and my libraries are built with the –g flag (along with –v, –arch i386 and –fvisibility-inlines-hidden).
Help would be much appreciated. Thanks.
Update: sorry for not updating this, my Mac port project was postponed. I never resolved this, but discovered that it actually only occurs in constructor bodies. I'll revisit this as and when I hit the problem again.
Have you tried these?
Why aren't my breakpoints working?
Not really an answer: You should make a bug report in the official Apple bugtracker. The chances are high that you get an answer sooner or later there - or perhaps it is really a bug.