Sign in to follow this  
liZHao

VC++ F5 and Ctrl+F5, I'm mad...

Recommended Posts

liZHao    108
Hi folks,

I'm stuck on a problem.. I wrote a OpenGL rendering framework using VC 2012. It loads model and shader files from hard drive. It works very well when I launch it by F5, BUT if I use Ctrl+F5, nothing is ever drawn on the screen.. Also under both 'modes', all files have been read in properly. I cannot figure out why, please help me if you have any ideas. Thanks in advance.

The libraries I used: glew 1.9, SDL 1.2, glm 0.9.3.4, C++11

Share this post


Link to post
Share on other sites
liZHao    108
Thanks for your answer Hodgman, regarding
[quote name='Hodgman' timestamp='1346217111' post='4974324']
Most likely you're relying on an uninitialized variable somewhere. Try turning the compiler's warning setting up to it's maximum level.
[/quote]
I maximized the warning levels but there are no variables uninitialized.

[quote name='Hodgman' timestamp='1346217111' post='4974324']
Do you use multi-threading or custom memory allocation?
[/quote]
Neither of them have been used so far. Though I found the rendering results may differ from time to time. E.g. very few times when I start the app only one of two meshes is drawn while other times nothing is drawn. Edited by liZHao

Share this post


Link to post
Share on other sites
Hodgman    51223
[quote name='liZHao' timestamp='1346243741' post='4974402']I maximized the warning levels but there are no variables uninitialized.[/quote]This just means there's no [i]obvious[/i] uninitialized variables, there still [i]might[/i] be some :/

e.g. This code creates a new uninitialized variable, but the compiler won't issue a warning about it:[code]MyStruct* data = (MyStruct*)malloc( sizeof(MyStruct) );[/code]

Share this post


Link to post
Share on other sites
SiCrane    11839
Note that even without weird creation mechanisms, if you pass the address of an uninitialized variable around, MSVC won't give you a warning. Ex:
[code]
void foo1(int a) {}
void foo2(int * a) {}

int main(int, char **) {
int a;
int b;
foo1(a); // C4700
foo2(&b); // no warning
}
[/code]

Share this post


Link to post
Share on other sites
bubu LV    1436
SiCrane - but that's normal usage of output argument. Why would you want warning for that? Then a lot of C style programs will give tons of warnings.

Share this post


Link to post
Share on other sites
BitMaster    8651
SiCrane did not say that should produce a warning. He said that is a situation where an uninitialized variable is used in a potentially dangerous context. That is an important point because the OP seems to assume no "uninitialized variable" warnings mean his program does not use them. Edited by BitMaster

Share this post


Link to post
Share on other sites
kunos    2254
Try to use CppCheck on it, it's usually pretty good at founding uninitialised variables in C++, it has already saved my neck more than a couple of times since I've started using it.

Share this post


Link to post
Share on other sites
brx    720
The thing I don't get about the unitialized variable assumption ist that both F5 and Ctrl+F5 launch the debug build (one with debugger attached, the other without) so the variables that stay uninitialized in release but initialized in debug should be initialized as well. Or am I missing something?

Try to attach the debugger after launching with Ctrl+F5 maybe that helps in seeing what happens?

Share this post


Link to post
Share on other sites
liZHao    108
I have found the reason: there is a boolean member variable indicating the visibility of a mesh and it has not been initialized explicitly.. thus in debug mode (F5) it is initialized with 'true' otherwise it is random..
What confuses me is why VC initializes a boolean variable with 'true'?

Share this post


Link to post
Share on other sites
SiCrane    11839
[quote name='brx' timestamp='1346255554' post='4974460']
The thing I don't get about the unitialized variable assumption ist that both F5 and Ctrl+F5 launch the debug build (one with debugger attached, the other without) so the variables that stay uninitialized in release but initialized in debug should be initialized as well. Or am I missing something?[/quote]
One of life's many little annoyances is that the MSVC CRT behaves differently depending on whether or not a debugger is attached during initialization. Take this code for example:
[code]
int main() {
std::vector<char *> vec;
for (int i = 0; i < 1000; i++) {
vec.push_back(new char);
}
std::sort(vec.begin(), vec.end());
ptrdiff_t min_diff = vec[1] - vec[0];
for (int i = 1; i < 999; i++) {
ptrdiff_t diff = vec[i + 1] - vec[i];
if (diff < min_diff) min_diff = diff;
}
std::cout << min_diff << std::endl;
}[/code]
With MSVC 2010 targeting x86, Debug with F5 spits out 64, Debug with Ctrl-F5 gives 48, Release/F5: 32, Release/Ctrl-F5: 16.

As long as your code relies only on defined behavior, then these differences don't really have much of an impact other than allocations using more or less memory than you might otherwise expect. However, once you dip into undefined or implementation defined behavior, like the contents of uninitialized memory, then these differences can give you all kinds of headaches. Edited by SiCrane

Share this post


Link to post
Share on other sites
SiCrane    11839
[quote name='liZHao' timestamp='1346257194' post='4974471']
I have found the reason: there is a boolean member variable indicating the visibility of a mesh and it has not been initialized explicitly.. thus in debug mode (F5) it is initialized with 'true' otherwise it is random..
What confuses me is why VC initializes a boolean variable with 'true'?
[/quote]
MSVC's debug heap fills uninitialized memory with [url=http://www.nobugs.org/developer/win32/debug_crt_heap.html]certain bit patterns[/url] to make debugging common errors easier to find. Note that they are all non-zero, which means translates into [tt]true[/tt] in most cases they are treated as a boolean value.

Share this post


Link to post
Share on other sites
kunos    2254
this is one of the things that really drives me mad about C++ ... there should be (is there?) a compiler switch to auto initialise every variable to zero and get rid of this '60 cold war age nonsense, I'd happily pay the performance penalty for that.

Share this post


Link to post
Share on other sites
Adam_42    3629
Another really simple way to get uninitialized variables with no compiler warnings is when they are class / struct member variables - the compiler won't complain if the constructor doesn't initialize all member variables.


It's not too hard to override global operator new so that it sets the memory to zero before returning it, just don't forget to do it for all the different variations (array version, nothrow version, etc). Of course there's an obvious performance cost to doing that, and it only works for heap allocations - doing that for stack allocated objects would need some help from the compiler, and Visual Studio can usually catch those in debug anyway.

Share this post


Link to post
Share on other sites
Mussi    4407
I can't remember the last time I ran into a problem like this. Rather than finding ways to ensure that variables are initialized to something random(should a boolean initialize to true or false?), I'd recommend you to train yourself in recognizing and avoiding code with undefined behaviour.

Share this post


Link to post
Share on other sites
Cornstalks    7030
[quote name='kunos' timestamp='1346257924' post='4974477']
this is one of the things that really drives me mad about C++ ... there should be (is there?) a compiler switch to auto initialise every variable to zero and get rid of this '60 cold war age nonsense, I'd happily pay the performance penalty for that.
[/quote]
That compiler switch is called "Use a different language." :) Even if there were such a switch though, I would beg everyone to not use it, because then you write poor code that is heavily tied to your compiler and compiler switches. Plus: what if library A authors relied on some specific default initialization values, but library B authors relied on some different default initialization values? What do you do if you want to use both library A and library B?

C++11 introduced the ability to initialize class members at declaration time, so that may help in some cases with missing/forgetting things. In the end, you just gotta get used to it if you're going to use C++ and train your eyes to pay attention to when a variable is declared, when it's assigned, and when it's used. The C++ mantra is "pay only for what you use" (C has this mantra even more so), and sometimes the desired value-assignment can't be done until a later point in time (so C & C++ ask: why waste instructions and CPU time writing a useless value?).

Share this post


Link to post
Share on other sites
krippy2k8    646
[quote name='kunos' timestamp='1346257924' post='4974477']
this is one of the things that really drives me mad about C++ ... there should be (is there?) a compiler switch to auto initialise every variable to zero and get rid of this '60 cold war age nonsense, I'd happily pay the performance penalty for that.
[/quote]

And make your code completely unsafe for anybody else that uses it.

Automatically initializing variables to zero is not just a trivial performance issue, it can have huge performance implications on some code and algorithms, and the potential benefits of doing so are marginal; it can eliminate some bugs, while making other bugs harder to track down.

Share this post


Link to post
Share on other sites
SiCrane    11839
[quote name='brx' timestamp='1346257669' post='4974476']
Thanks SiCrane, I didn't know that. I always thought it only depends on the build configuration.
[/quote]
The MSVC CRT heap behavior actually depends on a number of variables. One of them is operating system, this being because most of the time the CRT delegates allocations to the Windows API HeapAlloc() function, so if the OS behavior changes, the CRT behavior will change. However, older versions of MSVC takes a bit further. MSVC 2005 and earlier would only use HeapAlloc() if the OS was Win2000 or later. On earlier OS versions, they would use an internal heap management system... unless an environment variable was set to override the heap selection mechanism. MSVC 2008 defaulted to always using the OS heap, unless overridden by the environment variable. As far as I can tell MSVC 2010 got rid of the alternate heaps entirely, and instead adds a check to see if the OS is Win XP or 2003 Server, in which case it explicitly enables the low fragmentation heap. And to mix things up a bit, the OS heap itself depends on at least one environment variable. If _NO_DEBUG_HEAP is set to 1, then some of the behavior changes for when a debugger is present aren't used.

I also don't make any promises about this being a comprehensive list.

Share this post


Link to post
Share on other sites
Simian Man    1022
I normally use [url="http://valgrind.org/"]valgrind[/url] to check for things like this. It walks through your program and gives dynamic warnings on uninitialized variables and also memory leaks

Share this post


Link to post
Share on other sites
brx    720
[quote name='Simian Man' timestamp='1346343101' post='4974837']
I normally use [url="http://valgrind.org/"]valgrind[/url] to check for things like this. It walks through your program and gives dynamic warnings on uninitialized variables and also memory leaks
[/quote]
Vagrind would have been an option, but he stated he's using the Visual Studio and afaik valgrind does unfortunately not work in windows.

However, I just remembered that starting with VS2012 the static code analysis is included in all versions starting with professional (it used to be limited to higher versions before). That should have caught it as well. Additionally, they finally made the profiler and the concurrency visualizer available for VS professional as well.

Share this post


Link to post
Share on other sites
Hodgman    51223
Good static analysys tools should be good for this -- there's [url="http://www.gamedev.net/page/resources/_/technical/general-programming/mame-emulator-disease-memset-r2938"]an article on the site[/url] that talks about catching buggy memset calls that were supposed to initialize allocations but didn't.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this