链接不同版本的CRT运行库导致堆错误

前两天碰到一个运行库不匹配导致程序异常退出问题，现象是这样的：

首先是一个dll里的导出函数参数有一个std::string类型的出参，在可执行程序里调用了这个dll的库函数，出来后释放std::string对象就崩溃了

__declspec(dllimport) void getSomething(std::string &strOut);int main(){    std::string strOutput;    getSomething(strOutput);    return 0;}

getSomething方法中，对参数strOut赋值后，导致main函数退出时不能正常析构掉strOutput对象！

碰到这类问题，首先想到的是getSomething的实现代码写越界了，导致把main函数中的strOutput对象内存写坏使其不能正常析构，但这种情况会导致getSomething本身不能正常返回，所以可以排除；

还有一种可能就是调用约定错误，比如原来要求cdecl方式调用的函数，使用stdcall方式调用了，违反了参数压栈约定导致函数返回后堆栈不能正确的回滚，这种方式下函数是可以正常退出的，之前也都碰到过类似情况，特别是在调用c++成员函数的时候，可能会把已经压栈的this指针也复写掉（cdecl调用的函数会把保存this指针的ecx寄存器压栈保存）导致退出后this指针指向一个异常的位置。

通过观察实际的函数调用方式和调用前后的堆栈可以排除第二种可能。更奇怪的是，如果getSomething里对strOut赋值的字符串长度比较短，也不会导致strOut不能正常析构！

熟悉std::string实现的同学可以想到，std::string底层保存字符串的缓存是动态的，缺省会分配一个比较小的缓存，如果赋值的字符串大于这个初始缓存，就会重新分配一个缓存，而缓存分配是通过缺省的模板参数std::alloctor来实现的，最终调用CRT运行库的malloc函数来分配内存，看来是因为在getSomething里重新malloc后的缓存才会导致在main函数退出后不能正常释放。那就只有是在不同堆里分配的内存才会出现这样的问题，排查dll的工程文件后，果然发现一处异常：

RuntimeLibrary="1"

而在main函数的工程里，这个值是2，将dll修改为2后，问题解决！