Question

当我遇到内存访问错误时，我正在使用一些openFrameworks示例。经过一天缩小问题的时间后，我有一个相对纯粹的C ++代码的相当小的样本仍然导致内存访问错误。我会在这里发布所有内容，因为它很短。

有三个文件：testApp.cpp，main.cpp和testApp.h。

testApp.h：

#include <cstdlib>
#include <iostream>
#include <vector>
#include <string>
using namespace std;
class X {
public:

  X();
  virtual ~X();

private:

  vector<string> vertices;
  vector<string> colors;
  vector<string> normals;
  vector<string> texCoords;
  vector<string> indices;
  bool bVertsChanged, bColorsChanged, bNormalsChanged, bTexCoordsChanged, bIndicesChanged;
  int mode;
  string name;

  bool useColors;
  bool useTextures;
  bool useNormals;
};

class testApp{

public:
  void setup();

  X x1;
  X x2;
  vector<string> stroke;
};

testApp.cpp：

#include "testApp.h"

X::X() {}
X::~X() {}

void testApp::setup(){
  std::cout << stroke.size() << std::endl;


}

main.cpp中：

#define _GLIBCXX_DEBUG
#include "testApp.h"

int main( ){

    testApp* o = new testApp();
    o->setup();
    std::cout << o->stroke.size() << std::endl;

}

要编译，我键入：g++ -o testApp testApp.cpp main.cpp。（我正在使用Ubuntu 12.04和库存g ++编译器版本4.6.3，x86_64架构）。当我运行它时，我得到了这个输出：

18446744073709025734
0

第一个数字来自调用testApp :: setup，它打印出stroke.size（）（显然是不正确的）。第二个数字来自直接打印stroke.size（）。似乎存在某种内存问题，但我不知道从哪里开始，或者在哪里提交错误。

这似乎只有在指定testApp类时才会发生。如果你注释掉一个向量（甚至是一个bool），问题就会消失。如果你注释掉_GLIBCXX_DEBUG，问题也会消失，但那个标志应该是良性的AFAIK。有什么建议？我应该在哪里提交错误？还是有一些我忽略的东西？

另外，有人会介意在他们自己的计算机/编译器上尝试这个，看看他们是否会遇到同样的问题吗？

Answer 1

_GLIBCXX_DEBUG可能会更改标准库容器的定义，因此您的程序违反了One Definition Rule (ODR)。 X的定义在main.cpp转换单元和testApp.cpp转换单元中是不同的，产生未定义的行为。

这是一个g ++ bug，libc bug，还是我疯了（或者全是三个）？

1 个答案: