C ++中出现不稳定错误的常见原因？ [英] Most common reasons for unstable bugs in C++?

问题描述

我目前正在开展大型项目，大部分时间都在调试中。虽然调试是一个正常的过程，但是有一些错误，这是不稳定的，这些错误是开发人员最大的痛苦。该程序不起作用，有时候...有时候它有，而且没有什么可以做的。

可以对这些错误做些什么？最常见的调试工具（交互式调试器，手表，日志消息）可能会导致您无处不在，因为该错误将消失，只是为了再次出现。这就是为什么我要求一些启发式：这些错误最常见的原因是什么？我们应该调查哪些可疑代码来定位这样的错误？

让我开始列表：

1. 使用未初始化的变量。
   常见错误，如mMember =
   mMember;


2. 线程同步。
   有时它可以是
   的运气;


3. 使用非智能
   指针，取消引用无效的
   ;

还有什么？

解决方案

IME在许多项目中的基本问题是开发人员使用C ++的低级功能，如手册内存管理，C风格的字符串处理等，尽管它们很少有必要（然后仅仅很好地封装在类中）。这会导致内存损坏，指针无效，缓冲区溢出，资源泄漏等等。所有的时间都很好，干净的高级结构是可用的。

我是多年的一个大型（多个MLoC）应用程序的团队的一部分，应用程序的不同部分的崩溃错误数量与编程风格很相关在这些部分内使用。当被问及为什么他们不会改变他们的编程风格时，一些歹徒回答说，他们的风格一般会产生更多的表现。 （不仅如此，这也是一个事实，即客户比一个更稳定但更慢的程序，而不是一个不断崩溃的快速程序。而且，他们的大部分代码甚至不需要快速...）

至于多线程：在这里我不足以提供解决方案，但我认为是非常有价值的阅读。

编辑以解决评论中的讨论：

我没有写C风格的字符串处理性能不高。 （当然这个句子有很多否定，但是由于我感觉到错误，所以我试着很精确。）我所说的是，高级别的结构通常不那么有效： std :: vector 不是手动执行动态分配的C数组，因为它是一个动态分配的C数组。当然，有些情况下，根据特殊要求编码的东西的表现要优于任何一般的解决方案 - 但这并不一定意味着你必须诉诸于手动内存管理。这就是为什么我写道，如果这样的事情是必要的，那么只有很好的封装在类中。

但更重要的是：在大多数代码中，区别并不重要。有人点击后按钮0.01秒，或0.05秒无关紧要，所以即使5倍的速度增益与按钮的代码无关。无论代码是否崩溃，但是始终重要。

总结一下我的观点：首先让它正常工作。这是最好的使用成熟的现成的积木。然后测量。然后，使用成熟的成熟的习语，提高性能。

I am currently working on a large project, and I spend most of the time debugging. While debugging is a normal process, there are bugs, that are unstable, and these bugs are the greatest pain for the developer. The program does not work, well, sometimes... Sometimes it does, and there is nothing you can do about it.

What can be done about these bugs? Most common debugging tools (interactive debuggers, watches, log messages) may lead you nowhere, because the bug will disappear ... just to appear once again, later. That is why I am asking for some heuristics: what are the most common reasons for such bugs? What suspicious code should we investigate to locate such a bugs?

Let me start the list:

1. using uninitialized variables. Common misprints like mMember = mMember;
2. thread synchronization. Sometimes it can be a matter of luck;
3. working with non-smart pointers, dereferencing invalid ones;

what else?

解决方案

IME the underlying problem in many projects is that developers use low-level features of C++ like manual memory management, C-style string handling, etc. even though they are very rarely ever necessary (and then only well encapsulated in classes). This leads to memory corruption, invalid pointers, buffer overflows, resource leaks and whatnot. All the while nice and clean high-level constructs are available.

I was part of the team for a large (several MLoC) application for several years and the number of crashing bugs for different parts of the application nicely correlated to the programming style used within these parts. When asked why they wouldn't change their programming style some of the culprits answered that their style in general yields more performance. (Not only is this wrong, it's also a fact that customers rather have a more stable but slower program than a fast one that keeps crashing on them. Also, most of their code wasn't even required to be fast...)

As for multi-threading: I don't feel expert enough to offer solutions here, but I think Herb Sutter's Effective Concurrency columns are a very worthwhile read on the subject.

Edit to address the discussions in the comments:

I did not write that "C-style string handling is not more performant". (Certainly a lot of negation in this sentence, but since I feel misread, I try to be precise.) What I said is that high level constructs are not in general less performant: std::vector isn't in general slower than manually doing dynamically allocated C arrays, since it is a dynamically allocated C array. Of course, there are cases where something coded according to special requirements will perform better than any general solution -- but that doesn't necessarily mean you'll have to resort to manual memory management. This is why I wrote that, if such things are necessary, then only well-encapsulated in classes.

But what's even more important: in most code the difference doesn't matter. Whether a button depresses 0.01secs after someone clicked it or 0.05secs simply doesn't matter, so even a factor 5 speed gain is irrelevant in the button's code. Whether the code crashes, however, always matters.

To sum up my argument: First make it work correctly. This is best done using well-proven off-the-shelf building blocks. Then measure. Then improve performance where it matters, using well-proven off-the-shelf idioms.

这篇关于C ++中出现不稳定错误的常见原因？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！