跨模块传参数的教训

最新推荐文章于 2024-07-24 21:04:47 发布

ilvu999

最新推荐文章于 2024-07-24 21:04:47 发布

阅读量1.2k

点赞数

VC开发环境下C运行库有6个版本
DEBUG　单线程、多线程、多线程DLL
RELEASE　单线程、多线程、多线程DLL

不同模块分配的内存可以分配方式不一样，在另一个模块中释放时会导致错误。
其中单线程和多线程的内存管理模式不一样.

比如EXE调用DLL，DLL返加CString对象，这个对象的构造通过函数返回出栈的过程中，DLL中分配的内存，到EXE中析构就会报错。

每一个静态链接的CRT都会有一个默认堆吧，在EXE中NEW一个指针传递到DLL里去delete会产生堆破坏，是不是因为new在一个堆上，而delete在另一个堆上.

windows via c/c++ 关于DLL的讲述里面似乎有内容.
windows核心编程上有提到这个问题

谁申请，谁删除.

进程初始化时会有一个默认堆，如果EXE和DLL都静态链接CRT，那这时是不是有3个堆

对于静态CRT链接，EXE或者DLL中的NEW，DELETE都是在CRT各自创建的堆中去操作，所以不能跨模块释放，如果用GlobalAlloc代替NEW则不会，
这时因为GlobalAlloc实在进程的默认堆上分配的，是这样么.

在跨模块调用中传递stl容器的问题。

这是在项目中碰到的。
下面是代码：

//de.cpp
#include <string>
#include <iostream>
using namespace std;
extern "C" void getString(string & str);

int main(int argc,char ** argv)
{
    string str;
    getString(str);
    cout << str;
    return 0 ;
}

//dll.cpp
#include <string>
#include <iostream>
using namespace std;
extern "C" void getString(string & str)
{
int i;
str += "string modified.mybe cause a exception." ;
}

将dll.cpp连接成dll形式，运行de.exe有时候很正常，但有时候会发现有异常出现，异常是delete释放了一个非法的指针。这取决于连接的运行库是动态的还是静态的，他会在静态连接时出问题。
产生这个问题的原因是因为std::string类的内存分配器分配了内存，而在de.cpp里释放，两个模块分别有自己的运行堆，分配和释放没有在同一个堆里进行。
原因很简单，但是有时后就会忽略，尤其在模块很多和频繁使用stl容器的时候，当从别人那里得到一个模块接口时，如果有一个需要stl容器引用的接口时就要注意运行库的问题。

posted on 2005-11-24 10:24 psysun 阅读(845) 评论(6) 编辑收藏引用

评论:

# re: 在跨模块调用中传递stl容器的问题。2005-11-24 13:41 | 小明

link 的时候使用C++ Multi Thread Dll 库，就应该没问题回复更多评论

# re: 在跨模块调用中传递stl容器的问题。2005-11-24 17:39 | psysun

和多线程库没关系，是连接方式的问题。
总的原则是：在跨模块的接口里如果有用非常量stl容器引用作为参数的函数，那么就要保证这两个模块都用动态连接运行库方式连接的。用指针传递参数时分配和释放不再同一模块也有同样的问题。回复更多评论

# re: 在跨模块调用中传递stl容器的问题。2005-11-28 13:52 | hotjock

是不是用动态方式链接就能保证调用模块和被调用模块公用一个堆？还有就是STL如何释放或者讲何时释放由被调用模块重新new出来的空间（就象上面例子中的那样），采用动态链接就一定可以避免吗？回复更多评论

# re: 在跨模块调用中传递stl容器的问题。2005-11-28 19:23 | psysun

和动态链接没关系，重要的是共享运行时库。
因为stl容器都是以头文件形式定义的，所以每个模块编译后都至少有一份stl代码，在上面的例子里operator+=就是在dll.obj模块里，而~string()代码在de.obj，他们都使用了allocator<>，这个模版最后会用malloc和free管理内存，这时如果有一个模块静态链接了运行库，那么堆就不是唯一的，就会出异常了。
stl容器在分配内存时会根据算法用malloc分配一个比需要更大的内存，free掉原来的内存，用new(p) value_type(x)构造新对象，调用的是拷贝构造函数，用p->~value_type()析构对象。回复更多评论

# re: 在跨模块调用中传递stl容器的问题。2005-11-29 17:21 | hotjock

如同你最初给出的那个例子，怎样做就可以保证不出异常。

一个新手，希望讲的详细些。回复更多评论

# re: 在跨模块调用中传递stl容器的问题。 2005-12-11 23:30 | psysun
再连接时用动态方式链接运行库就能避免了。vc里就是/MD

跨模块传参数的教训

今天遇到一个比较奇怪的crash问题，这里记录下。这个crash是由QA设置了一些不合理的参数引起的，还好QA当时保存了Dump文件，让我们可以慢慢分析，从而找出代码中隐藏的问题。

这里先简单介绍下ATL/WTL里字符串的设计:
(1)每个CString都有自己的串头(内含引用计数，数据长度，已分配内存长度)，紧接着后面是真正的数据。
因为是基于引用计数，所以相同的多个CString可以共享同一份数据。

struct CStringData
{
     long nRefs;      // reference count
     int nDataLength;
     int nAllocLength;
     // TCHAR data[nAllocLength]

    TCHAR* data()
    { return (TCHAR*)( this + 1); }
};

(2)每个未初始化CString都会指向同一固定的全局数据，内部引用计数、数据长度、已分配内存长度、内容分别为-1，0，0，0

// Globals

// For an empty string, m_pchData will point here
// (note: avoids special case of checking for NULL m_pchData)
// empty string data (and locked)
_declspec(selectany) int rgInitData[] = { -1, 0, 0, 0 };
_declspec(selectany) CStringData* _atltmpDataNil = (CStringData*)&rgInitData;
_declspec(selectany) LPCTSTR _atltmpPchNil = (LPCTSTR)(((BYTE*)&rgInitData) + sizeof(CStringData));

inline CString::CString()

{

Init();

}

inline void CString::Init()

{ m_pchData = _GetEmptyString().m_pchData; }

static const CString& __stdcall _GetEmptyString()

{

return *(CString*)&_atltmpPchNil;

}

(3)字符串析构时会检测是否已经分配内存，是否其他没有人用（引用计数小于0），都满足后才会最终释放内存。

inline CString::~CString()
//   free any attached data
{
     if (GetData() != _atltmpDataNil)
    {
         if (InterlockedDecrement(&GetData()->nRefs) <= 0)
              delete[] (BYTE * )GetData();
    }
}

用Windbg打开Dump文件，输入!analyze -v 让它自动分析Crash时的情况，最终发现Crash在ATL/WTL字符串的析构函数 ~CString()里的delete语句, 然后我们通过分析传入参数，发现外部传入的是一个没有初始化的CString，既然是没有初始化的CString，那应该都是指向初始字符串的固定内存，也就不会满足条件 if (GetData() != _atltmpDataNil)，为什么会跑到里面去呢？

这里关键原因就是这个CString是跨模块传递过来的，比如你DLL里有个导出函数void SetValue(CString strValue)，然后你外部Exe传递一个未出始化的字符串CString str; SetValue(str); 这时就会Crash。根本原因是因为传入的字符串是在Exe里构造，但是在DLL里析构，Exe里的未初始化str指向的是Exe模块自己的全局初始值Exe! _atltmpDataNil, 而DLL内CString的全局初始值是Dll自己的Dll!_atltmpDataNil, 两者比较当然不相等，而后面的 if (InterlockedDecrement(&GetData()->nRefs) <= 0)又会把引用计数从-1改成-2，接下来就会试图delete这块不是new出来的全局内存，当然会Crash了。

这个Bug一直没有发现的原因是QA一直设置的都是有效参数，也就不会引起传入未初始化的CString的情况，但这次意外却暴露了我们代码中隐藏的问题。

知道了原因，接下来就是如何改了？方法很多，可以用传引用的方式CString&；也可以传C方式的字符串LPCTSTR；也可以还是传CString, 但是在传之前先做下长度判断，以确保已经出始化。

另外提醒下如果要在模块(DLL)之间传递内存，要确保C/C++运行库要用DLL的方式(MD), 这样跨模块new和delete时他们会共享同一个内存堆，不同模块之间相互new和delete才不会有问题。

测试工程: DllStringTest

经典问题了，MD虽然可以解决，但个人感觉，还是应该养成哪里分配哪里释放的好。跨DLL释放总不是很好。。

我觉得还是传char *比较保险，不要传类

恩,跨模块返回一个未初始化的CString会有同样的问题,
所以跨模块还是用C语言的字符串方式比较保险。