记录一下这次查 bug
有一个 class BackendTexture 里面有几个 private member（图一）
他有一个 default constructor（图二）
这个 class 编译成 .lib 后静态链接到我的代码里（使用的是同一个编译器 msvc19 和 clang 都试过）
然后我只要调用这个 constructor，他就会把我当前栈帧的 36byte 大小的内存全部设成 0，同时自己并没有被初始化（如图三）
我进到 disassemble 看 就发现我的编译器只在栈上给他留了 64 个 byte 的空间，但是这个 class 实际上会占 100 个byte，说明我程序里用的 header 和 编译库时候的 header 不一样，再检查（图六）的 header 就会发现如果启用 vulkan 那么这个类里就会多一个 VulkanAlloc，这个 struct （图七）和其他几个加起来就占 36 个 byte。问题就很清楚了
这个bug看上去是真挺诡异的 记一下 不然下次遇到又得调半天
一开始还以为是调用约定或者 esp/ebp 重设的问题，上手调试之后才发现不是那么回事（
有一个 class BackendTexture 里面有几个 private member（图一）
他有一个 default constructor（图二）
这个 class 编译成 .lib 后静态链接到我的代码里（使用的是同一个编译器 msvc19 和 clang 都试过）
然后我只要调用这个 constructor，他就会把我当前栈帧的 36byte 大小的内存全部设成 0，同时自己并没有被初始化（如图三）
我进到 disassemble 看 就发现我的编译器只在栈上给他留了 64 个 byte 的空间，但是这个 class 实际上会占 100 个byte，说明我程序里用的 header 和 编译库时候的 header 不一样，再检查（图六）的 header 就会发现如果启用 vulkan 那么这个类里就会多一个 VulkanAlloc，这个 struct （图七）和其他几个加起来就占 36 个 byte。问题就很清楚了
这个bug看上去是真挺诡异的 记一下 不然下次遇到又得调半天
一开始还以为是调用约定或者 esp/ebp 重设的问题，上手调试之后才发现不是那么回事（