编译器优化使程序崩溃 [英] Compiler optimization makes program crash
问题描述
我在C ++ / Qt中编写一个包含图形文件解析器的程序。我使用 g ++ 编译项目。
I'm writing a program in C++/Qt which contains a graph file parser. I use g++ to compile the project.
在开发时，我不断地比较我的低级解析器关于优化和调试信息的不同编译器标记之间的层，加上Qt的调试标志（打开/关闭qDebug（）和Q_ASSERT（））。
While developing, I am constantly comparing the performance of my low level parser layer between different compiler flags regarding optimization and debug information, plus Qt's debug flag (turning on/off qDebug() and Q_ASSERT()).
问题，其中唯一正确运行的构建是没有任何优化的。所有其他版本，即使使用 -O1 ，似乎以另一种方式工作。它们由于未满足的断言而崩溃，当编译时没有 -O ... 标志时，它们会满足。即使使用 -Wall ，代码也不会产生任何编译器警告。
Now I'm facing a problem where the only correctly functioning build is the one without any optimization. All other versions, even with -O1, seem to work in another way. They crash due to unsatisfied assertions, which are satisfied when compiled without a -O... flag. The code doesn't produce any compiler warning, even with -Wall.
我非常确定我的程序中的一个错误，这似乎只有有害的优化启用。问题是：我甚至在调试程序时找不到它。解析器似乎从文件读取错误的数据。当我运行一些简单的测试用例，他们运行完美。当我运行一个更大的测试用例（一个图表上的路径计算直接从文件读取），在文件中有一个不正确的读取，我不能解释。
I am very sure that there is a bug in my program, which seems to be only harmful with optimization being enabled. The problem is: I can't find it even when debugging the program. The parser seems to read wrong data from the file. When I run some simple test cases, they run perfectly. When I run a bigger test case (a route calculation on a graph read directly from a file), there is an incorrect read in the file which I can't explain.
我应该从哪里开始跟踪这个未定义的行为的问题？ 这种不同的行为可能涉及哪些优化方法？（我可以一个接一个地启用所有标志，但我不知道有多少编译器标志，但 -O .. 。我知道有很多，所以这将需要很长的时间。）一旦我知道哪个类型的错误，我相信我迟早找到它。
Where should I start tracking down the problem of this undefined behavior? Which optimization methods are possibly involved within this different behavior? (I could enable all flags one after the other, but I don't know that much compiler flags but -O... and I know that there are a lot of them, so this would need a very long time.) As soon as I know which type the bug is of, I am sure I find it sooner or later.
如果你能告诉我哪些编译器优化方法可能是这种问题的候选者，你可以帮助我很多。
You can help me a lot if you can tell me which compiler optimization methods are possible candidates for such problems.
推荐答案
在优化版本中通常会出现几类错误，通常不会出现在调试版本中。
There are a few classes of bugs that commonly arise in optimized builds, that often don't arise in debug builds.
-
未初始化的变量。编译器可以捕获一些但不是全部。看看你的所有构造函数，看看全局变量。等等。特别寻找未初始化的指针。在调试版本中，内存被重置为零，但在发行版本中不是。
Un-initialized variables. The compiler can catch some but not all. Look at all your constructors, look at global variables. etc. Particularly look for uninitialized pointers. In a debug build memory is reset to zero, but in a release build it isn't.
使用已超出范围的临时值。例如，当您在函数中返回对本地临时的引用时。这些通常在调试生成中工作，因为堆栈被填充更多。
Use of temporaries that have gone out of scope. For example when you return a reference to a local temporary in a function. These often work in debug builds because the stack is padded out more. The temporaries tend to survive on the stack a little longer.
数组超过了临时数的写入。例如，如果你在一个函数中创建一个数组作为一个临时数，然后写一个元素超过结束。再次，堆栈将在调试（用于调试信息）中有额外的空间，您的溢出将不会击中程序数据。
array overruns writing of temporaries. For example if you create an array as a temporary in a function and then write one element beyond the end. Again, the stack will have extra space in debug ( for debugging information ) and your overrun won't hit program data.
这篇关于编译器优化使程序崩溃的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
