I have a program which causes Memory corruption while debugging, but runs perfectly fine in release. To add strangeness, program fulfils its function before "crashing" (it saves data to a file). Can that mean Visual Studio simply doesn't like my program, or does it mean I have a serious bug I need to repair? In general, if Debug mode crashes, does it always mean there is problem with a program, or is it possible there is simply problem with the way program runs in debug mode, so I should not worry too much?
Asked
Active
Viewed 269 times
0
-
12The most likely scenario is that you have a serious bug that needs fixing. – juanchopanza Apr 03 '13 at 15:22
-
1It's probably a bug, but in certain cases, mixing Debug and Release builds of exe's and dll's can cause the Debugger to wrongly think you have a memory problem. – Roger Rowland Apr 03 '13 at 15:23
-
1You should verify that to be sure. Without being sure, it's a bad assumption. – tenfour Apr 03 '13 at 15:23
-
It's not okay. *"Runs fine"* is not a valid test for "Will always run fine". – Drew Dormann Apr 03 '13 at 15:41
-
*"Can that mean Visual Studio simply doesn't like my program"* - I was unaware that Visual Studio maintains preferences for certain programs. – JBentley Apr 03 '13 at 16:05
3 Answers
4
It is almost certainly a bug in your application, which will need tracking down and fixing.
There are many types of bugs that lead to undefined behaviour. Some types of undefined behaviour (such as memory corruption) can manifest themselves as seemingly random failures that occur much later in the program than the bug that's caused them.
In debug mode, Visual Studio goes out of its way to ensure that such failures occur as early as possible and are as prominent as possible. In release mode, the focus is on performance.
There is a good summary of some of the differences between debug and release in https://stackoverflow.com/a/312352/367273
2
No it is not OK. Most likely this means that some variable or pointer is not iniatalized. In debug mode such uninitalized values are frequently defaulted to 0, while shuch defaulting is not used in release (optimized) code.
tletnes
- 1,958
- 10
- 30
-
2"Most likely this means that some variable or pointer is not iniatalized" - not necessarily. Could be any kind of _undefined behavior_, like - heap corruption, invalidated pointer (not non-initialized), race condition (in case of mutlithteading), etc, etc. – Kiril Kirov Apr 03 '13 at 15:25
-
@Kiril it does mean those things are possible, but in my experiance un-initialized variables and popinters make up the majority of these sorts of errors. – tletnes Apr 03 '13 at 15:36
-
Sure, I up-voted, just mentioning and you could have added it into your answer. – Kiril Kirov Apr 03 '13 at 17:27
0
It means you have serious bug you need to repair. The most likely reason is that you are using uninitialised variables. In VS this is the commonest cause of programs running differently in debug and release.
john
- 7,897
- 29
- 27