可恶的BSTR和它娘家人们

[libinfei8848]

COM中为了实现各语言之间的相互协作，定义几套专用的东西：其中就有BSTR和它的娘家人：sysallocstring,sysfreestring等用于专门处理BSTR的。
然而这几天我在程序中莫名的遇到一些问题：BSTR被无缘无故的释放了。查了很久的原因，最后发现sysallcostring
并没有像MSDN上说的那样工作，发现这样：

//pStr2是有效的BSTR变量
BSTR pStr1 = SysAllocString(pStr2); 

上面的代码再跟踪的时候发现一个问题就是，执行完后发现pStr1的地址和pStr2的地址是一样的。MSDN说的是申请一块新的内存存放BSTR。。。

于是我下面的代码就莫名其妙的被释放掉了，代码如下：

_bstr_t wsClauseForLink(L"MASTEROBJID='");
//pDevObjID是有值的BSTR变量		
wsClauseForLink += pDevObjID;     //(1)
wsClauseForLink += L"' OR SLAVEROBJID='";
wsClauseForLink += pDevObjID;     //(2)
wsClauseForLink += L"'"; 

在执行到（1）的时候因为是“+=”操作符，pDevObjID会先生成一个_bstr_t的临时变量和wsClauseForLink 相加，在这句执行完后，临时变量就要释放掉了，结果发现把pDevObjID释放掉了（跟踪后发现生成临时变量的时候调用_bstr_t的构造函数时候调用了SysAllocString，结果新生成的临时变量内部的指针和pDevObjID地址一样，所以释放掉了pDevObjID），这样就造成了（2）执行时候，pDevObjID可能已经成为了乱码。



更让人郁闷的是这种问题是间歇性发作了，很难找到问题所在。。。坛里的同志们，你们是否遇到这样的问题呢？

[arong1234]

BSTR是很核心的类型，所以我相信这一定是哪儿用错了。但是你给出的代码片断无法看出在哪错了

[arong1234]

很显然，+=接受的是一个常引用，根本不会创建临时对象，所以也不会出现你所谓的临时对象析构导致被释放的问题。怀疑你跨线程使用BSTR又没有保护，导致数据被破坏

[libinfei8848]

[Quote=引用 2 楼 arong1234 的回复:]
很显然，+=接受的是一个常引用，根本不会创建临时对象，所以也不会出现你所谓的临时对象析构导致被释放的问题。怀疑你跨线程使用BSTR又没有保护，导致数据被破坏
[/Quote]
如果是这样的话，能有什么办法能准确的去定位到说这个问题是跨线程调用造成的？

[libinfei8848]

你说的跨线程调用是有可能的，公司的产品是net做界面然后调用C++的组件，我的代码用C++的测试框架测试是没有任何问题，但是在公司的产品中跑就时常出现问题。

[arong1234]

这不可能直接看出证据的，只有细致的调试才能找到证据。只要你能说确实存在跨线程调用，其实根本不用证据就可以说明了，因为只要你懂跨线程，就知道这一定是可能的[Quote=引用 3 楼 libinfei8848 的回复:]
引用 2 楼 arong1234 的回复:
很显然，+=接受的是一个常引用，根本不会创建临时对象，所以也不会出现你所谓的临时对象析构导致被释放的问题。怀疑你跨线程使用BSTR又没有保护，导致数据被破坏

如果是这样的话，能有什么办法能准确的去定位到说这个问题是跨线程调用造成的？
[/Quote]

[搬了20多年的砖]

BSTR应该非常的稳定,com内部这个是主要类型,不可能有你说的问题,认真查自已的代码.

[skyworth98]

sp

[Quote=引用 6 楼 blukercn 的回复:]
BSTR应该非常的稳定,com内部这个是主要类型,不可能有你说的问题,认真查自已的代码.
[/Quote]