Why do all my local static variables function perfectly in release but not so in debug mode?

TonEpskamp-0986 31

Many thanks to all of you who helped me to get my release executable running. I discovered this misery when developing a debug version. I could correct all those failures by replacing some of my local statics by globals. Becoming a little frustrated I compiled a release version without those stupid replacements! Big surprise: all my problems melted like snow in the sun. In debug mode I detected the most unexpected (change of) values of my local statics.That was the reason I gave the release mode its chance by compiling a release version. Help me understanding the same code in both debug and release versions responding so incomprehensibly differently. I am using Visual Studio Community 2019. Do I have to replace all my local statics by globals? I don't know of any possibility of increasing the space for local statics? I can't believe in a similar solution because of the perfectly running release mode. I counted 312 local statics.

Viorel 112.1K Reputation points

2022-09-30T05:11:23.903+00:00

Which code does not work?
TonEpskamp-0986 31 Reputation points

2022-09-30T08:23:30.06+00:00

A static local variable of a function will keep its assigned value(s) through different successive calls. To achieve this local statics have a special memory part of the program in common to be stored at. The debugger of VS instructed me that the above didn't apply for my local statics: their values were NOT kept and I even detected for different local statics the same invalid values (of -258)! Can you imagine my surprise when running the release executable without the slightest problem! It is a disguisting dilemma: the targets of debug and release seem to be inverted! Normally you develop a perfectly running debug version to create a release version! I created a perfectly running release version and remain unable to do the same for my debug version: TRAGICALLY FUNNY!
RLWA32 40,286 Reputation points

2022-09-30T09:19:00.42+00:00

Which version of VS Community 2019 are you using (most recent is 16.11.19)? Can you share a minimal sample that reproduces the issue?
Viorel 112.1K Reputation points

2022-09-30T10:50:48.59+00:00

Maybe there are some invalid pointers or indices that are not always observed and are difficult to diagnose.
TonEpskamp-0986 31 Reputation points

2022-10-02T20:59:31.68+00:00

Yes indeed 16.11.19 because I proved unable to install VS Communitiy 2022. I am not convinced the difference between this latter and VS Communitiy 2019 would be that important for me! And also because downloading VS Communitiy 2022 ended up to be using the Build tools V 142 in stead of V143. So now I am left with a release version pefectly running everything and a debug version with the most incredible values of (some of) my local statics.
I have to admit I never coded any compiler nor something similar but I am convinced if I had to do just that it would nearly be impossissible to achieve that unlucky combination of producing a perfect release and imperfect debug result. Simply because the difference between both products only should be the extra code the debug version would claim for its extra data due to its debug ability. After one first should have developed the release producing code successfully and then one should have to inserted the extra debug producing code. Actually I did something completely else: a Mathematica-like program for 12-18 years aged students of mathematics and my test is always independent of debug/release version producing all solutions of the 6.000 included mathematical exercises. Believe me (or not so) the release version ended without any error and the debug version ended with 1 exercise unsolved and 1 exercise producing a runtime error both due to local statics errors! Whenever this problem solved I will be left with the fact that Microsoft OneDrive is preventing all my executables from showing up on the screen!
TonEpskamp-0986 31 Reputation points

2022-10-02T21:12:35.193+00:00

I am thinking I do understand your question very well because using pointers will always remain a dangerous type of coding. So always pointers might produce that kind of errors. But I think and certainly hope that a perfectly running release version should guarantee sufficient hope of excluding that kind of an error because it would always and only occur independent of the debug/release version anyhow!
TonEpskamp-0986 31 Reputation points

2022-10-03T10:13:58.77+00:00

Yes indeed 16.11.19 because I proved unable to install VS Communitiy 2022. I am not convinced the difference between this latter and VS Communitiy 2019 would be that important for me! And also because downloading VS Communitiy 2022 ended up to be using the Build tools V 142 in stead of V143. So now I am left with a release version pefectly running everything and a debug version with the most incredible values of (some of) my local statics.
I have to admit I never coded any compiler nor something similar but I am convinced if I had to do just that it would nearly be impossissible to achieve that unlucky combination of producing a perfect release and imperfect debug result. Simply because the difference between both products only should be the extra code the debug version would claim for its extra data due to its debug ability. After one first should have developed the release producing code successfully and then one should have to inserted the extra debug producing code. Actually I did something completely else: a Mathematica-like program for 12-18 years aged students of mathematics and my test is always independent of debug/release version producing all solutions of the 6.000 included mathematical exercises. Believe me (or not so) the release version ended without any error and the debug version ended with 1 exercise unsolved and 1 exercise producing a runtime error both due to local statics errors! Whenever this problem solved I will be left with the fact that Microsoft OneDrive is preventing all my executables from showing up on the screen!
TonEpskamp-0986 31 Reputation points

2022-10-03T10:16:14.797+00:00

I am thinking I do understand your question very well because using pointers will always remain a dangerous type of coding. So always pointers might produce that kind of errors. But I think and certainly hope that a perfectly running release version should guarantee sufficient hope of excluding that kind of an error because it would always and only occur independent of the debug/release version anyhow!
Viorel 112.1K Reputation points

2022-10-03T14:48:24.423+00:00

In my world, such hope is insufficient.
RLWA32 40,286 Reputation points

2022-10-03T15:14:02.67+00:00

Without a sample that reproduces the issue there's not much that the community can do to assist you.

If you believe this to be a compiler bug in VS2019 then you should use the VS2019 feedback mechanism to report a problem.
TonEpskamp-0986 31 Reputation points

2022-10-24T09:54:29.447+00:00
I will show you the next example I myself executed in my program:
In a function I declared and contnued (in C++):

static short dp=0; // because in C++ zero initializing is standard: so "=0" should be redundant; if (abs(dp)>1) dp=0;

With a breakpoint on the second line! I ensured that my executable would reach thIs breakpoint at its first occurrence. To my immense surprise the value of dp was -258. So I stepped through this actual line to make dp==0. This variable dp's function is to limit this functions recursivity. Then I stepped through this function without any surprises and this function reached its target regularly: BUT ONLY BY MY INTERVENTION. The most funny thing however is that I already earlier detected this terribly wrong value of dp. And I decided that somewhere in this function and its subfunctions this wrong value of -258 was caused by my own code: NO! Its cause was the wrong initializing! Stronger still I am well aware of this happening. So my question is: "Do I have to replace all my static locals by globals?". I happen to believe this question's answer should be "NO"! I have to admit my program is growing bigger and bigger. But is finished now. I have now successful both debug and release executables with stupid code included! And I will remain a passionate programmer!