can not obtain local variable value in Visual Studio 2008

Hello everyone,


When remote debugging a release version binary on a remote machine using Visual Studio 2008, there is error message from local host machine in Visual Studio when I try to see some local variable values.

The error message is (1st message is displayed when my mouse stops at the variable in Locals, the 2nd message is what is displayed when I pressed refresh button for the specific local variable),

--------------------
The value for this item is stale dues to a problem that occured while evaluating it. Hover your cursor over the refresh button for details.

newNumbers Cannot obtain value of local or argument 'newNumbers' as it is not available at this instruction pointer, possibly because it has been optimized away. int
--------------------

Such issue only happens with release version, debug version is fine. Any ideas how to solve this? I need to debug release version.


thanks in advance,
George

Quote:

---

...possibly because it has been optimized away.

---

I'd say your variable has been optimized away. Is there a reason why you need to debug a release version on a remote machine ? Use your variable to do something worthwhile that cannot be optimized away (write to file, or use it as input somewhere). If a variable that is crucial to your programs success has been optimized away, maybe your program has some logical problems.

Quote:

---

Originally Posted by nvoigt

I'd say your variable has been optimized away. Is there a reason why you need to debug a release version on a remote machine ? Use your variable to do something worthwhile that cannot be optimized away (write to file, or use it as input somewhere). If a variable that is crucial to your programs success has been optimized away, maybe your program has some logical problems.

---

But it's worth bearing in mind that variables can appear and disappear if they are only used locally in a particular section of code.

I agree, if possible, debug problems with debug builds unless it's impossible to reproduce in debug build. If it's impossible to reproduce in debug build, then it's most likely one of two things:
1. bad coding, for example relying on variables being re-loaded when the compiler may not think it is required (modifying pointers that the compiler doesn't realize pointing to local variables, for example).
2. speed related problems - usually related to multiple threads/processes, where fast code is able to show the problem.

I have almost always found that debugging release code requires debugging at assembler level, since what the compiler does in optimized code is not conducive to debugger understanding what is going on. I'm not saying assembler level debugging is easy - but it's often a better way to understand what actually happens in your code. And it's most likely that the problems with release code not working correctly is related to the way that the code is generated, or something close to "what exactly became of my source code".

Note that Visual Studio certainly does strange things to code in optimized mode - it shuffles assignments around, if/else code is most likely split apart by miles. Large functions are nearly impossible to follow if you don't look at both the source and the assembler (and understand quite well what the compiler actually does in it's code generation).

--
Mats