Visual C ++多线程调试/发布问题 [英] Visual C++ Multi-threaded Debug/Release Issue

问题描述

我在VS C ++ 2008中编写了一个程序。在调试期间，运行时库是多线程调试。然后我觉得它已经足够好并且编译了一个发布版本。输出到窗口无法正常工作，程序通常表现不佳。



经过多长时间将消息框放入程序后我确定最初的问题是写的到显示器。我没有看到任何东西看起来错了所以我看了一下发布配置下的属性。似乎运行时库有四种设置，两种用于静态链接，两种用于动态。最初我选择了静态链接，因此可以选择静态库的调试版本和发布版本。只是为了笑，我用静态库的调试版编译了发布程序。该程序与库的调试版一起运行，并且不与库的发行版一起运行。



那么问题是什么？很明显，如果我不知道问题是什么，我就无法修复我的代码中的问题。



Bob Van Tuyl
[e-mail]



PS我知道库选择表明该程序存在线程问题。我不知道是不是这样，因为我正在使用MFC库创建一个窗口应用程序。 Visual Studio 2008中的所有库选择似乎都是多线程的。我写的代码不直接使用线程（虽然幕后的Windows可以）。



阅读下面描述的关于从调试到发布的文章我现在相信我有一个更难以捉摸的错误，已被该库的调试版屏蔽。至少这是我将在下一次会议中探索的地方。感谢所有回答这个模糊问题的人。

I've written a program in VS C++ 2008. During debugging the Runtime Library is Multi-threaded Debug. Then I decided it was good enough and compiled a release version. Output to the window failed to work and the program generally did not behave well.

After much time placing Message Boxes in the program I determined that the initial problem is in writing to the display. Nothing I looked at looked wrong so I took a look at the Properties under the Release Configuration. It appears that there are four settings for the Runtime Library, two for static linking and two for dynamic. Initially I chose static linking so that made the choice of the debug and release versions of the static library. Just for grins I compiled the release program with the debug version of the static library. The program runs with the debug version of the library and does not run with the release version of the library.

So what is the problem? It is pretty clear that I cannot "fix" the problem in my code if I don't have any idea what the issue is.

Bob Van Tuyl
[e-mail]

P.S. I know the library choice suggests that the program has a thread issue. I don't know if that is the case because I am creating a single window application using the MFC library. All the library choices in Visual Studio 2008 seem to be Multi-threaded. The code that I wrote does not employ threads directly (although Windows behind the scenes could).

After reading the article described below about moving from debug to release I now believe that I have a more elusive bug that has been masked by the debug version of the library. At least that is where I will spend the next session exploring. Thanks to all that have answered this vague question.

推荐答案

看看oldie-goldie Newcomer的文章：Surviving the Release Version [ ^ ]。

Have a look at the oldie-goldie Newcomer's article: "Surviving the Release Version"[^].

我认为在此之前出现的帖子帮助您了解有没有足够的信息。那么，不要指望模式然后一些抽象的猜测，纯粹的屁股射击。



线程是这样的事情，只能通过合理调试来解决这个问题，应该在理论上证明正确性。你可以拥有一个运行良好数月甚至一年的计划，并且，在纯粹的意外中，它会陷入灾难。这是因为涉及内在随机性。而且，编写正确的多线程应用程序是非常可能的，而且在很多情况下，它甚至都不太困难。



所以，我的想法是：这可能不是您的应用程序正确运行并因某些错误而失败，可能会更糟糕：在您的开发计算机上似乎工作的事实是真正的错误，实际上它没有错误地失败，并且，在生产中，它合法地失败了。它发生了。为什么不同？定时。在不同的环境中，时间稍微改变了。



当代码的设计包含竞争条件时会发生这样的事情： http://en.wikipedia.org/wiki/Race_condition [ ^ ]。

当我第一次读到这篇文章时，它有一个更具信息性的名称：不正确的依赖关系执行时间。这件事真正的实际危险并不在于失败。问题是竞争条件允许事物以不确定的方式工作并产生正确工作的错觉。考虑一下线程，一个将一些共享变量乘以一个常量，另一个添加一个常量。并且所有共享对象都完美同步。但是，如果共享变量等于2，则结果可能是2 * 3 + 4或（2 + 4）* 3.它是10或18，具体取决于首先出现的线程。考虑你期望10，并且第一个线程总是通过一些随机时间原因更快地访问这个变量。现在，假设时间略有偏移，所以第一个线程会有一个小延迟，比如说，因为有些用户当时启动了MS Word。然后你会得到18，即使你只有10，在测试的许多天。



请不要急于说我不能拥有它，因为我从来没有在一个线程中将值乘以3并在另一个线程中加上4。我不知道;你可以做其他事情。:-)



再次，没有足够的信息;这只是猜测。然而，竞争条件将是我的主要嫌疑人。首先检查。

- SA

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

取决于它究竟是如何行为不端，但在正常的C ++（一般不受管理）中你所描述的是由指针问题引起的。不同的解释是因为不同的库有不同的代码路径可以改变程序的运行方式。



同样可以说一个线程问题。它可能会更好，因为你没有正确受不同线程访问的受保护数据。不同的库影响t他的时间和/或数据的管理方式，因此似乎更好。

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.

这篇关于Visual C ++多线程调试/发布问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！