构造函数调用了错误的“this”指针。这是堆栈损坏吗？答案

【问题标题】：Constructor called with wrong "this" pointer. Is this stack corruption?构造函数调用了错误的“this”指针。这是堆栈损坏吗？
【发布时间】：2012-03-01 13:22:45
【问题描述】：

编辑： 在评论者的帮助下，我已经弄清楚了。回答我标题中提出的问题：不，这不是堆栈损坏，它的 gdb 报告了错误的值。该程序实际上按预期运行并且具有正确的this 指针。促使我发布此问题的实际错误行为可能与我在此处描述的问题完全无关。

首先是一个警告。我相信这是一个内存损坏问题，除了“彻底检查你的代码”之外，我通常不会期待答案，但我已经看到这种行为反复出现，并希望你们中的一些人对这个问题以及我如何可以找到它的来源。

我目前正在实现一个区间静态分析，它跟踪 C 程序中可能的变量范围。我的基本间隔类的复制构造函数如下所示：

itvt::itvt(const itvt& i)
  : _i(i.type == INTBV ? new intbv_intervalt(i.i()) : NULL),
    _f(i.type == FLOAT ? new float_intervalt(i.f()) : NULL),
    type(i.type), other_bottom(i.other_bottom) 
{ }

现在，我发现了一个内存损坏错误，并设法将其追溯到以下 sn-p 代码：

itvt itvt::get_split(bool le) const
{
   itvt result(*this);
   [...]
}

使用gdb，发现调用构造函数似乎没有构造“结果”对象：

Breakpoint 1, itvt::get_split (this=0x1016af560, le=false) at itv.cpp:517
517   itvt result(*this);
(gdb) n
519   if(is_singleton() || is_bot())
(gdb) print result
$3 = {
  _i = {
    _M_ptr = 0x7fff5fbfe100
  }, 
  _f = {
    _M_ptr = 0x7fff5fbfed60
  }, 
  type = 1606410016, 
  other_bottom = 255
}
(gdb) print *this
$4 = {
  _i = {
    _M_ptr = 0x1020833a0
  }, 
  _f = {
    _M_ptr = 0x0
  }, 
  type = itvt::INTBV, 
  other_bottom = false
}

深入研究，我发现在复制构造函数内部，“this”指针指向了错误的对象：

Breakpoint 1, itvt::get_split (this=0x1016af560, le=false) at itv.cpp:517
517   itvt result(*this);
(gdb) print &result
$5 = (itvt *) 0x7fff5fbfdee0
(gdb) s     
itvt::itvt (this=0x7fff5fbfdf80, i=@0x1016af560) at itv.cpp:500
500     type(i.type), other_bottom(i.other_bottom)
(gdb) print this
$6 = (itvt * const) 0x7fff5fbfdf80

由于“结果”在地址 0x7fff5fbfdee0 的堆栈上分配，我希望复制构造函数中的“this”指针指向相同的地址。相反，它指向 0x7fff5fbfdf80。

看起来复制构造函数正在初始化一些东西，而不是调用它的堆栈上的“结果”对象。事实上，我可以很好地访问构造函数初始化的内存位置：

Breakpoint 1, itvt::get_split (this=0x1016af560, le=false) at itv.cpp:517
517   itvt result(*this);
(gdb) s    
itvt::itvt (this=0x7fff5fbfdf80, i=@0x1016af560) at itv.cpp:500
500     type(i.type), other_bottom(i.other_bottom)
(gdb) finish
Run till exit from #0  itvt::itvt (this=0x7fff5fbfdf80, i=@0x1016af560) at itv.cpp:500
itvt::get_split (this=0x1016af560, le=false) at itv.cpp:519
519   if(is_singleton() || is_bot())
(gdb) print *((const itvt*) (0x7fff5fbfdf80))
$7 = {
  _i = {
    _M_ptr = 0x1016b6d10
  }, 
  _f = {
    _M_ptr = 0x0
  }, 
  type = itvt::INTBV, 
  other_bottom = false
}

我的第一个问题：“this”指针指向错误对象的事实可以解释为正常行为吗？这似乎是一些奇怪的内存损坏问题，但也许我错过了一些东西。

我正在使用 g++ 和“-O0 -ggdb”标志进行编译，并对所有内容进行了全新的重新编译。这是我的 g++ 版本：

leo@scythe ai$ g++ --version
i686-apple-darwin11-llvm-g++-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

我的第二个问题：如果是内存损坏，您对我如何追查源头有什么建议。我通常使用 gdb 跟踪此类问题的根本原因，但我现在不知道该去哪里找。

这不是我第一次遇到这种特定行为。在查看其他人的错误时，我已经看到它发生了。我从来没有真正直接设法直接解决它，它只是停止发生，或者至少在其他一些代码更改后成为一个可见的问题。这让我相信，使用 gdb 查看堆栈可能只是一个奇怪的人工制品。

感谢您提供的任何建议或见解。

编辑： 这是itvt类的相关sn-p：

class itvt
{
protected:
  typedef std::auto_ptr<intbv_intervalt> iptrt;
  typedef std::auto_ptr<float_intervalt> fptrt;
  iptrt _i;
  fptrt _f;
public:
  typedef enum {INTBV, FLOAT, OTHER} itv_typet;
  itv_typet type;

  bool other_bottom;

  //copy constr
  itvt(const itvt& i);

  inline intbv_intervalt& i() { return *_i; }
  inline float_intervalt& f() { return *_f; }
  inline const intbv_intervalt& i() const { return *_i; }
  inline const float_intervalt& f() const { return *_f; }

  itvt get_split(bool le) const;

  [...]
};

【问题讨论】：

感谢您提供的信息，这在另一种情况下对我来说很有趣。不，itvt 类完全无聊/非虚拟。 itvt 或其成员不涉及虚拟性或继承性。
只是一个问题：您的gdb 版本是最新的吗？我见过使用旧版本的gdb 和更新版本的编译器导致gdb 显示错误内容的情况。（先验，这应该只是在更改主要版本时才会出现的问题：当 g++ 4.0.0 第一次出现时，gdb 需要一段时间才能赶上。但你永远不知道。）
第二点是，当您执行 s 进入函数时，一些调试器（我不确定 gdb ---我已经在 VS 中看到过）不会进入函数以设置本地堆栈帧。这会导致所有值都不正确（当由调试器查看时）。
究竟是什么错误？据我所知，您没有说明实际错误是什么。您也不会在初始化后显示result，因此您只是在正确输入未定义的范围之前打印result 的地址。构造函数返回后&result 是什么？如果在构造后的第二个语句中将 result 赋值给它会发生什么？
感谢 cmets。 @JamesKanze 我正在使用 GNU gdb 6.3.50-20050815（Apple 版本 gdb-1705），它似乎相当旧（新的似乎是 7.4）。我正在运行 Mac，所以我使用的是 Xcode 附带的标准构建环境（我相信......）。更新这个直接进入我的待办事项列表。我将修改代码以打印我通过 gdb 获取的内存地址，以查看 gdb 是否说的是真话。

标签： c++ gdb g++ corruption

【解决方案1】：

第二个问题：使用 valgrind，这正是您所需要的。它跟踪每个分配/空闲，并告诉您是否尝试使用释放的内存以及许多其他内容。它会显示内存损坏。

【讨论】：

【解决方案2】：

我在评论者的帮助下弄清楚了：看起来 gdb 没有说实话（可能是由于旧的 gdb 版本）。该程序实际上按预期运行。

促使我调查问题的实际错误行为与对象初始化完全无关。

【讨论】：