今天遇到一个比较奇怪的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
posted on 2012-07-13 21:27 Richard Wei 阅读(3840) 评论(4)  编辑 收藏 引用 所属分类: windbg

FeedBack:
# re: 跨模块传参数的教训
2012-07-14 00:42 | 10年码农
经典问题了,MD虽然可以解决,但个人感觉,还是应该养成哪里分配哪里释放的好。跨DLL释放总不是很好。。  回复  更多评论
  
# re: 跨模块传参数的教训[未登录]
2012-07-14 07:38 | 123
又是一个自造轮子引发的血案……  回复  更多评论
  
# re: 跨模块传参数的教训
2012-07-16 09:28 | zuhd
我觉得还是传char *比较保险,不要传类  回复  更多评论
  
# re: 跨模块传参数的教训
2012-07-16 10:04 | Richard Wei
@zuhd
恩,跨模块返回一个未初始化的CString会有同样的问题,
所以跨模块还是用C语言的字符串方式比较保险。  回复  更多评论
  

只有注册用户登录后才能发表评论。
网站导航: 博客园   IT新闻   BlogJava   博问   Chat2DB   管理