具有协变返回类型的方法在 VC++ 上崩溃

Methods with covariant return types crashes on VC++

本文关键字：VC++ 崩溃 方法 返回类型      更新时间：2023-10-16

以下代码在使用clang或gcc(在macOS上)编译时似乎运行良好，但在使用MS Visual C++ 2017编译时崩溃。在后者上，foo_clone对象似乎已损坏，程序崩溃，行foo_clone->get_identifier()上出现访问冲突。

如果我删除协变返回类型(所有克隆方法都返回IDO*)，或者删除std::enable_shared_from_this，或者当所有继承都变为虚拟时，它确实适用于 VC++。

为什么它适用于 clang/gcc 而不是 VC++？

#include <memory>
#include <iostream>
class IDO {
public:
virtual ~IDO() = default;
virtual const char* get_identifier() const = 0;
virtual IDO* clone() const = 0;
};
class DO
: public virtual IDO
, public std::enable_shared_from_this<DO> 
{
public:
const char* get_identifier() const override { return "ok"; }
};
class D : public virtual IDO, public DO {
D* clone() const override {
return nullptr;
}
};
class IA : public virtual IDO {};
class Foo : public IA, public D {
public:
Foo* clone() const override {
return new Foo();
}
};
int main(int argc, char* argv[]) {
Foo* foo = new Foo();
Foo* foo_clone = foo->clone();
foo_clone->get_identifier();
}

消息：

在 foo.exe： 0xC0000005：访问冲突读取位置0x0000000000000004 0x00007FF60940180B引发异常。

这似乎是VC++的错误编译。当enable_shared_from_this不存在时，它会消失，就像一条红鲱鱼;问题只是被掩盖了。

一些背景：解析C++中被覆盖的函数通常通过 vtables 进行。但是，在存在多重和虚拟继承以及协变返回类型的情况下，必须应对一些挑战，以及满足这些挑战的不同方法。

考虑：

Foo* foo = new Foo();
IDO* ido = foo;
D* d = foo;
foo->clone(); // must call Foo::clone() and return a Foo*
ido->clone(); // must call Foo::clone() and return an IDO*
d->clone(); // must call Foo::clone() and return a D*

请记住，无论如何，Foo::clone()都会返回Foo*，从Foo*转换为IDO*或D*并不是一个简单的无操作。在完整的Foo对象中，IDO子对象位于偏移量 32(假设 MSVC++ 和 64 位编译)，D子对象位于偏移量 8。从Foo*到D*意味着向指针添加 8，而获取IDO*实际上意味着从IDO子对象所在的Foo*加载信息。

但是，让我们看一下为所有这些类生成的 vtable。用于IDO的 vtable 具有以下布局：

0: destructor
1: const char* get_identifier() const
2: IDO* clone() const

用于D的 vtable 具有以下布局：

0: destructor
1: const char* get_identifier() const
2: IDO* clone() const
3: D* clone() const

插槽 2 之所以存在，是因为基类IDO具有此功能。插槽 3 在那里，因为这个函数也存在。我们可以省略这个插槽，而是在调用站点生成额外的代码以从IDO*转换为D*吗？也许吧，但效率会降低。

Foo的 vtable 如下所示：

0: destructor
1: const char* get_identifier() const
2: IDO* clone() const
3: D* clone() const
4: Foo* clone() const
5: Foo* clone() const

同样，它继承了D的布局并附加自己的插槽。我实际上不知道为什么有两个新插槽 - 它可能只是一个次优算法，出于兼容性原因而坚持使用。

现在，我们在这些插槽中放入什么 对于Foo类型的具体对象？插槽 4 和 5 简单获取Foo::clone().但是该函数返回一个Foo*，因此它不适合插槽 2 和 3。对于这些，编译器创建调用主版本并转换结果的存根(称为 thunks)，即编译器为插槽 3 创建类似以下内容：

D* Foo::clone$D() const {
Foo* real = clone();
return static_cast<D*>(real);
}

现在我们进入错误编译：出于某种原因，编译器在看到此调用时：

foo->clone();

调用的不是插槽 4 或 5，而是插槽 3。但是插槽 3 返回一个D*！然后代码只是继续使用该D*作为Foo*，或者换句话说，你会得到与你所做的相同的行为：

Foo* wtf = reinterpret_cast<Foo*>(
reinterpret_cast<char*>(foo_clone) + 8);

这显然不会有好结果。

具体来说，发生的情况是在调用foo_clone->get_identifier();编译器想要将Foo* foo_clone强制转换为IDO*(get_identifier要求其this指针是IDO*，因为它最初是在IDO中声明的)。正如我之前提到的，IDO对象在任何Foo对象中的确切位置都不是固定的;它取决于对象的完整类型(如果完整对象是Foo则为 32，但如果它是从Foo派生的类，则可能是其他东西)。因此，若要执行转换，编译器必须从对象内部加载偏移量。具体来说，它可以加载位于任何Foo对象偏移量 0 处的"虚拟基指针"(vbptr)，该指针指向包含偏移量的"虚拟基表"(vbtable)。

但请记住，我们有一个损坏的Foo*，它已经指向真实对象的偏移量 8。所以我们访问偏移量 0 的偏移量 8，那里有什么？好吧，碰巧的是，enable_shared_from_this对象weak_ptr，它是空的。因此，我们为 vbptr 获取 null，并且尝试取消引用它以获取对象崩溃。(虚拟基础的偏移量存储在 vbtable 中的偏移量 4，这就是为什么您得到的崩溃地址是 0x000...004.)

如果删除所有协变恶作剧，vtable 将缩小为一个不错的单个条目以供clone()，并且不会出现错误编译。

但是，如果删除enable_shared_from_this，为什么问题会消失？好吧，因为偏移量 8 处的东西不是weak_ptr内的某个空指针，而是DO子对象的 vbptr。(一般来说，继承图的每个分支都有自己的 vbptr。IA有一个Foo共享的，DO有一个D共享的。并且该vbptr包含将D*转换为IDO*所需的信息。我们的Foo*真的是伪装的D*，所以一切都恰好正确进行。

附录

MSVC++ 编译器有一个未记录的选项来转储对象布局。这是它与enable_shared_from_thisFoo的输出：

class Foo   size(40):
+---
0  | +--- (base class IA)
0  | | {vbptr}
| +---
8  | +--- (base class D)
8  | | +--- (base class DO)
8  | | | +--- (base class std::enable_shared_from_this<class DO>)
8  | | | | ?$weak_ptr@VDO@@ _Wptr
| | | +---
24  | | | {vbptr}
| | +---
| +---
+---
+--- (virtual base IDO)
32  | {vfptr}
+---
Foo::$vbtable@IA@:
0  | 0
1  | 32 (Food(IA+0)IDO)
Foo::$vbtable@D@:
0  | -16
1  | 8 (Food(DO+16)IDO)
Foo::$vftable@:
| -32
0  | &Foo::{dtor}
1  | &DO::get_identifier
2  | &IDO* Foo::clone
3  | &D* Foo::clone
4  | &Foo* Foo::clone
5  | &Foo* Foo::clone
Foo::clone this adjustor: 32
Foo::{dtor} this adjustor: 32
Foo::__delDtor this adjustor: 32
Foo::__vecDelDtor this adjustor: 32
vbi:       class  offset o.vbptr  o.vbte fVtorDisp
IDO      32       0       4 0

这里没有：

class Foo   size(24):
+---
0  | +--- (base class IA)
0  | | {vbptr}
| +---
8  | +--- (base class D)
8  | | +--- (base class DO)
8  | | | {vbptr}
| | +---
| +---
+---
+--- (virtual base IDO)
16  | {vfptr}
+---
Foo::$vbtable@IA@:
0  | 0
1  | 16 (Food(IA+0)IDO)
Foo::$vbtable@D@:
0  | 0
1  | 8 (Food(DO+0)IDO)
Foo::$vftable@:
| -16
0  | &Foo::{dtor}
1  | &DO::get_identifier
2  | &IDO* Foo::clone
3  | &D* Foo::clone
4  | &Foo* Foo::clone
5  | &Foo* Foo::clone
Foo::clone this adjustor: 16
Foo::{dtor} this adjustor: 16
Foo::__delDtor this adjustor: 16
Foo::__vecDelDtor this adjustor: 16
vbi:       class  offset o.vbptr  o.vbte fVtorDisp
IDO      16       0       4 0

以下是对返回调整clone垫片的一些清理拆卸：

mov         rcx,qword ptr [this]  
call        Foo::clone ; the real clone  
cmp         rax,0 ; null pointer remains null pointer
je          fin
add         rax,8 ; otherwise, add the offset to the D*
jmp         fin
fin:  ret

下面是错误调用的一些清理反汇编：

mov         rax,qword ptr [foo]  
mov         rcx,rax  
mov         rax,qword ptr [rax] ; load vbptr  
movsxd      rax,dword ptr [rax+4] ; load offset to IDO subobject 
add         rcx,rax  ; add offset to Foo* to get IDO*
mov         rax,qword ptr [rcx]  ; load vtbl
call        qword ptr [rax+24]  ; call function at position 3 (D* clone)

以下是崩溃呼叫的一些清理拆解：

mov         rax,qword ptr [foo_clone]  
mov         rcx,rax  
mov         rax,qword ptr [rax] ; load vbptr, loads null in the crashing case
movsxd      rax,dword ptr [rax+4] ; load offset to IDO subobject, crashes
add         rcx,rax  ; add offset to Foo* to get IDO*
mov         rax,qword ptr [rcx]  ; load vtbl
call        qword ptr [rax+8]  ; call function at position 1 (get_identifier)
相关文章：