Visual C++ Multi-threaded Debug/Release Issue

I thing the posts which appeared before this one helped you to understand that there is no enough information. So, don't expect mode then some abstracted speculations, pure shooting off the hips.

Threading is such a thing which cannot be fixed by just debugging reasonably well, the correctness should be proven theoretically. You can have a program which works well for months or even year, and, by pure accident, fall into a disaster. This is because intrinsic randomness is involved. And still, it's quite possible to write correct multithreaded applications, and, in many cases, it's not even too difficult.

So, my idea is: this might be not that your application ran correctly and failed by some mistake, it could be worse: the fact that is seemed to work on your development computer was the real mistake, in fact it was not failing by mistake, and, in production, it "legitimately" failed. It happens. Why the difference? Timing. In different environment, timing has shifted just a bit.

Such things happen when the design of your code contained race conditions: http://en.wikipedia.org/wiki/Race_condition[^].
When I first read about this, it has a more informative name: "incorrect dependency of the time of execution". The real practical danger of this thing is not that something fails. The problem is that race condition allows things to work in indeterminate way and create an illusion of correct work. Consider tho threads, one is multiplying some shared variable by a constant, another one adds a constant. And all the shared object are perfectly synchronized. However, if, say, the shared variable equals 2, the the result could be either 2*3 + 4 or (2+4) * 3. It's 10 or 18, depending on what thread comes first. Consider you expect 10, and the first thread always gets access to this variable a bit sooner, by some random timing reason. Now, imagine that timing is slightly shifted, so the first thread gets a tiny delay, say, because some user started MS Word at that time. And then you get 18, even though you got only 10, during many days of testing.

And please don't rush to say "I cannot have it, because I never multiplied a value by 3 in one thread and add 4 in another one. I don't know; you could do something else. :-)

Again, there is no enough information; and this is just speculations. However, the race condition would be the primary suspect to me. Check it up first.

—SA

Depends on exactly how it is misbehaving but in normal C++ (unmanaged in general) what you described is caused by a pointer problem. The difference is explained because the different libraries have different code paths which alter how the program runs.

The same can be said about a thread issue as well though. It might work better because you haven't correctly protected data that is accessed by different threads. The different libraries impact the timing and/or the way the data is managed and so it seems to work better.

Thanks to all that responded to this vague question. The solution was suggested by the paper "Surviving the Release Version" suggested above. The actual solution was a class with an incomplete initialization during construction. I actually visited each class and initialized all simple variables (those not automatically initialized by its' own constructor). While doing this I would test the release version and one of the more complex modules (classes) needed some additional initialization.

Now that I've fixed this problem I must express my disapointment with Microsoft for creating the situation in the first place. Back when I started in this business (in one of the first time sharing machines developed at UC Berkeley) our debuggers worked in the same environment as the final product. Thus not debugging meant removing the symbol table and running the program (and no other changes). This meant that bugs could be found and then reliably fixed in the environment in which the program would run. Oh well, time moves on and thoughts about how to accomplish a goal change, perhaps not always for the better...

Bob Van Tuyl

Thanks to all...