【问题标题】:g++ optimization -O3 causing strange stackdump error?g++ 优化 -O3 导致奇怪的堆栈转储错误?
【发布时间】:2016-07-11 07:57:32
【问题描述】:

首先,我两个月前才开始编程 C/C++(但在 Java 方面有更多经验),所以我对 C/C++ 的经验还很远。我正在写一篇论文,并且正在使用/扩展为之前的研究编写的其他代码。

现在,这个错误绝对是我遇到过的最奇怪的错误,我花了将近 3 个小时才找到并缩小到我可以重现它的最基本形式。最后,我有这两个文件,其中包含以下代码

c.hh:

#ifndef C_HH_
#define C_HH_

class complex {
public:
    double re;
};
#endif

test.cc:

#include <iostream>
#include "c.hh"

int main(int argc, char **argv) {
    complex* c;
    c->re = 0.0;

    for (int i = 0; i < 3; ++i) {
        c->re = (c->re) + (i==1)?0:1;
    }

    std::cout << c->re;
}

我唯一可以取出并且仍然会发生错误的行是 c.re 的初始化,即“c->re = 0.0;”。但是,我将其保留,因为即使我删除了代码的下部,如果没有此行,错误仍然会发生,因为 c.re 尚未初始化(或者我认为?)。

我发现重现错误所必需的所有其他内容,即

1) for 循环。如果 i=1,2,3 的行分开写,不会导致错误。

2) i! 的极限!例如如果 i 仅从 0 运行到 2 将不会导致错误。仅在至少 3 次迭代后发生。

3)显式赋值“c->re = (c->re)+”,用“+=”代替“=(c->re)+”不会报错。

4) i "(i==1)?0:1" 的评估和(!) 条件检查。使用 if(..) 这样做也会导致错误,但如果不使用 i 则不会导致错误,或者不执行条件检查。

5) c.re. 的输出即“std::cout re;”。简单地评估 c.re ("c->re;") 不会导致错误。如果只有一个输出而根本没有评估 c.re,它也不会导致错误。通过 "fprintf(stdout, "%d", c->-re);" 做同样的事情也会导致错误。

同样非常重要的是,只有当我像这样编译代码时才会出现错误:

g++ -O3 -c -o test.o test.cc
g++ -O3 -o test test.o c.hh

如果省略“-O3”不会导致错误,所以我认为这就是代码产生这个对我来说难以理解的错误的真正原因。 请注意,使用 -O3 是因为正如我提到的,这段代码是为研究编写的,这样的函数可能会被调用数百万次,所以最好尽可能优化。然而,我只是根据给我的内容改编了这个“约定”,并不真正了解细节以及使用或不使用它的确切结果。

最重要的是,每当出现错误时,程序根本不会运行。意思是,即使我将任何形式的输出放在任何地方,即使在代码的第一行,运行“test”也会立即导致错误并且不输出任何内容。

最后,我在尝试执行程序“test”时遇到的错误如下:

0 [main] test 10720 cygwin_exception::open_stackdumpfile: Dumping stack trace to test.exe.stackdump

其中 stackdump 文件包含以下内容:

Exception: STATUS_ACCESS_VIOLATION at eip=00401770
eax=00000001 ebx=0028CC8C ecx=8001801F edx=00000000 esi=0028CCA0 edi=0028CCA4
ebp=0028CC68 esp=0028CC50 program=D:\somepath\test\src\test.exe, pid 13768, thread main
cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B
Stack trace:
Frame     Function  Args
0028CC68  00401770 (00000001, 0028CC8C, 800280E8, 61007D35)
0028CD28  61007D9A (00000000, 0028CD84, 61006DC0, 00000000)
End of stack trace

正如您可能会说的那样,我对这个问题非常迷茫并且不知道发生了什么,因为似乎没有任何编程“逻辑”的原因来解释为什么会发生这种情况。 在这个非常简单的代码中我做错了什么吗? 无论如何要“解决”这个问题而不必忽略 -O3 优化?或者这可能不那么重要?

希望我提供了足够的信息,感谢您的帮助!

【问题讨论】:

    标签: c++ optimization stack-dump


    【解决方案1】:
    complex* c;
    c->re = 0.0;
    

    这是非常未定义的行为。第一行创建了一个指向complex 类型对象的指针,但实际上并没有创建对象本身。指针将指向任意位置,因此使用 -&gt; 取消引用它是有问题的。

    如果您想要使用指针,则需要实际创建对象本身,然后将指针指向它。这就像替换一样简单:

    complex *c;
    

    与:

    complex *c = new complex();
    

    你当然应该在完成后释放它,使用:

    delete c;
    

    然而,这里没有需要动态分配的对象,因为它的生命周期是严格本地的。您可以改为使用以下内容来证实一个对象:

    object c;
    

    然后确保将其与. 一起使用,而不是-&gt;,例如:

    c.re = 0.0;
    

    在这种情况下,不需要delete


    此外,不要在您的大部分问题中阅读太多关于它可能会起作用或不起作用的可能令人困惑的情况。

    一旦你开始做未定义的事情,所有的赌注都没有了,程序几乎可以为所欲为。

    【讨论】:

    • complex c; 将是一个更简单的选择(作为一个 java 程序员,OP 可能不知道这一点)
    • 看起来这确实是个问题,我想我仍然需要更多地习惯 C++,直到现在主要使用纯 C。有趣的是,我实际上是从现有代码中复制了这种类型的编码,它工作并确实产生了经过测试和正确的结果,所以我假设简单地初始化成员就足以正确“定义”对象,但事实证明并非如此。不知道为什么这在原始代码中有效,然后哈哈。
    • 值得指出的是,可以零初始化成员,而不是将零分配为第二步:complex c = {0.0};complex c = {}; pre-c++11,complex c{}; 否则。
    • @user3451943:请注意,未定义的行为可能表现出的一种行为是“做你期望的”——仅仅因为你在某些情况下得到了你期望的结果并不意味着你实际上在做事情正确!
    • @Hurkyl,没错,UB 有时可能会起作用的事实是它最阴险的特性 :-)
    猜你喜欢
    • 2017-10-09
    • 1970-01-01
    • 2020-12-03
    • 2013-01-07
    • 2020-04-16
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2012-02-29
    相关资源
    最近更新 更多