My Engine isn't working in Release-mode
Author
Hi!
Every time, I want to start my Engine in the Release mode (instead of debug), it crashes! Does anyone had a similar problem?
Yeah, I had a bug in my code where it crashed in release mode once too. I fixed it though.
I think it's happened to everyone at some point or another.
Here are a couple common things to check for (though this is not a complete list)
- Uninitialized variables. In debug variables initialize to 0, typically, and at least on Microsoft compilers I think memory on the heap initializes to 0xCD repeatedly (or was that unused heap memory?). This means your variable which is normally valid, has any possible value in it. This goes for enums as well!
- ASSERT statements. If asserts do more than check a condition, ie they actually DO something like "ASSERT((result = Func()) == NULL);", it will NOT be executed in release builds. Both "result" will not be assigned, and "Func()" will not be called.
I'd say start there.
Here are a couple common things to check for (though this is not a complete list)
- Uninitialized variables. In debug variables initialize to 0, typically, and at least on Microsoft compilers I think memory on the heap initializes to 0xCD repeatedly (or was that unused heap memory?). This means your variable which is normally valid, has any possible value in it. This goes for enums as well!
- ASSERT statements. If asserts do more than check a condition, ie they actually DO something like "ASSERT((result = Func()) == NULL);", it will NOT be executed in release builds. Both "result" will not be assigned, and "Func()" will not be called.
I'd say start there.
Ya, we had that one often.
Look into your constructors. You have uninitialized variables. In debug it will often initialize them to garbage, and bool to true. But in Release, I think depending on your compiler configs, will automatically initialize them to zero, and bools to false. Don't rely on this anyway, always initialize them.
You probably just forgot a variable or two :). That was our case, every time!
Look into your constructors. You have uninitialized variables. In debug it will often initialize them to garbage, and bool to true. But in Release, I think depending on your compiler configs, will automatically initialize them to zero, and bools to false. Don't rely on this anyway, always initialize them.
You probably just forgot a variable or two :). That was our case, every time!
Author
Well, ok... What was it? What do I have to look for? :(
EDIT: Wow! so many answers, and I was still typing ;) Gotta read them first...
EDIT: Wow! so many answers, and I was still typing ;) Gotta read them first...
Quote:Original post by WuTzThat depends what "Crash" means. If it's an access violation, what address? What line of code causes it? Are you sure all pointers are valid on that line?
Well, ok... What was it? What do I have to look for? :(
If it won't even start up, it's probably manifest related
If it's a bluescreen, it's probably driver or hardware related.
Quote:Original post by DaivukThe compiler won't initialise them to anything - their value depends on whatever happened to be in memory before it and is essentially random.
But in Release, I think depending on your compiler configs, will automatically initialize them to zero, and bools to false.
In Debug mode, certain things are done for you to make it easier to detect bugs. However, these have the flip side of behaving in a deterministic manner, which means that your code can end up depending on behaviour that the debug runtimes give you. An example is when you allocate or free memory, the runtime will fill it with special patterns which make it easier to discover uninitialised or release memory being used.
You also need to understand that you can attach a debugger in release mode. You can modify the default Release configuration which might make it easier to make sense of what is happening, as otherwise it will be very confusing.
You also need to understand that you can attach a debugger in release mode. You can modify the default Release configuration which might make it easier to make sense of what is happening, as otherwise it will be very confusing.
I've had it happen too! I think you need to inspect your computer for forks and see if your code has any bugs in them. Because it's most likely that those cause the crash to happen.
Without posting more details it might be hard to find help. What language are you using? What output (if any) do you get?
Taking a stab in the dark: If you're coding in C or C++, the first thing you'll want to check for is uninitialized variables. The compiler usually sets all new variables to a default value like 0 in debug mode, but in release the same variables could be anything. An uninitialized bool could be equal to 23. Uninitialized pointers would incorrectly pass null checks. Dogs and cats living together, etc.
If all else fails, drop in a printf at every other line, see which is the last one that outputs. The crash will be after that line.
edit: Wow, in the time it took me to type that, five other people beat me to it with good answers. LOL
Taking a stab in the dark: If you're coding in C or C++, the first thing you'll want to check for is uninitialized variables. The compiler usually sets all new variables to a default value like 0 in debug mode, but in release the same variables could be anything. An uninitialized bool could be equal to 23. Uninitialized pointers would incorrectly pass null checks. Dogs and cats living together, etc.
If all else fails, drop in a printf at every other line, see which is the last one that outputs. The crash will be after that line.
edit: Wow, in the time it took me to type that, five other people beat me to it with good answers. LOL
Author
Ok. It crashes in mvcrt.dll or msvcrt.dll, something like that. I only see Assembler code, but I will take a look, what happens before that crash. And I found some uninitialized variables. Maybe it works, when I init them all. Thanks for that fast help! :)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
