回答編集履歴
1
修正
test
CHANGED
@@ -1,11 +1,125 @@
|
|
1
|
-
原因が
|
1
|
+
事象が発生するコードの検証中に原因が分かった為、こちらに記載します。
|
2
2
|
|
3
3
|
|
4
4
|
|
5
|
-
|
5
|
+
###原因
|
6
6
|
|
7
|
+
他サイトから引用した以下の様なコードが原因でした。
|
8
|
+
|
9
|
+
Qiita 等でも記事にされているメジャーな使い方の様です。
|
10
|
+
|
11
|
+
```C++
|
12
|
+
|
13
|
+
BSTR str = CComBSTR(L"ABC");
|
14
|
+
|
15
|
+
```
|
16
|
+
|
17
|
+
###原因詳細
|
18
|
+
|
7
|
-
|
19
|
+
上述のコードの処理は以下の通りとなります。
|
20
|
+
|
21
|
+
①CComBSTR クラスのコンストラクタが呼び出され、L"ABC"のメモリが確保される。
|
22
|
+
|
23
|
+
②str に L"ABC" の参照が渡される。
|
24
|
+
|
25
|
+
③CComBSTR クラスのデストラクタが呼び出され、L"ABC"のメモリが解放される。
|
8
26
|
|
9
27
|
|
10
28
|
|
29
|
+
つきまして、str は見掛け上 L"ABC" が確保されたアドレスを参照していますが、
|
30
|
+
|
31
|
+
COM 内部処理的には L"ABC" のアドレスが解放された状態となります。
|
32
|
+
|
33
|
+
|
34
|
+
|
35
|
+
質問本文では CComBSTR の呼び出しが一度のみのコードを記載しておりましたが、
|
36
|
+
|
37
|
+
該当のコードの引数である var の値を設定する際に CComBSTR による値設定を行っていたことがそもそもの原因となります。
|
38
|
+
|
39
|
+
|
40
|
+
|
41
|
+
以下サンプルの様に、上記の処理を複数回実行すると同様の事象が発生します。
|
42
|
+
|
43
|
+
|
44
|
+
|
45
|
+
###サンプル
|
46
|
+
|
47
|
+
```C++
|
48
|
+
|
49
|
+
int main() {
|
50
|
+
|
51
|
+
BSTR abc = SysAllocString(L"ABC");
|
52
|
+
|
53
|
+
SysFreeString(abc);
|
54
|
+
|
55
|
+
BSTR def = SysAllocString(L"DEF");
|
56
|
+
|
57
|
+
SysFreeString(def);
|
58
|
+
|
59
|
+
}
|
60
|
+
|
61
|
+
```
|
62
|
+
|
63
|
+
3行目(SysFreeString(abc);)の時点で abc は解放されていますが、
|
64
|
+
|
65
|
+
4行目でも abc の参照先は変わらず、参照先には L"ABC" が残っています。
|
66
|
+
|
67
|
+
|
68
|
+
|
69
|
+
これは COM 内部のメモリ管理をしている機能に起因しています。
|
70
|
+
|
71
|
+
COM API が確保するメモリはスタックでもヒープでもなく、COM 管理下のメモリです。
|
72
|
+
|
73
|
+
COM が自管理下にあるメモリを参照しているか否かの判断は、実際に参照されているかではなく、
|
74
|
+
|
75
|
+
COM 内部のメモリ管理をする機能が参照しているか否かで判断されます。
|
76
|
+
|
77
|
+
SysFreeString は、この機能上での参照を解除します。
|
78
|
+
|
79
|
+
|
80
|
+
|
81
|
+
そして5行目で再度 L"DEF" を確保する際、確保する先は先程解放した L"ABC" が格納されているアドレスです。
|
82
|
+
|
83
|
+
つまり、この時点でまだ L"ABC" のアドレスを参照している abc の値も変わります。
|
84
|
+
|
85
|
+
|
86
|
+
|
87
|
+
ちなみに以下でも同様です。
|
88
|
+
|
89
|
+
```C++
|
90
|
+
|
91
|
+
int main() {
|
92
|
+
|
93
|
+
BSTR abc = CComBSTR(L"ABC");
|
94
|
+
|
95
|
+
BSTR def = CComBSTR(L"DEF");
|
96
|
+
|
97
|
+
}
|
98
|
+
|
99
|
+
```
|
100
|
+
|
101
|
+
###その他
|
102
|
+
|
103
|
+
同関数内のスコープの異なる位置でメモリ確保をしたり、質問本文の様にルーチンを分離して実行してみたり、BSTR と CComBSTR を混在させたり、などなど検証している内に事象が発生しないパターンが存在することもわかりました。
|
104
|
+
|
105
|
+
|
106
|
+
|
11
|
-
|
107
|
+
検証が雑だったせいかもしれませんが、
|
108
|
+
|
109
|
+
時により二度目のメモリ確保の際に、一度目に解放したメモリ以外を確保するパターンが確認できました。
|
110
|
+
|
111
|
+
|
112
|
+
|
113
|
+
問題となっている事象の原因が既に分かっていたのと、条件がきれいにまとめられなくなりそうだったので細かい検証は見送りましたが、タイミングや環境如何では不都合なく動く可能性もある様です。
|
114
|
+
|
115
|
+
###解決策
|
116
|
+
|
117
|
+
CComBSTR クラスのコンストラクタを利用した BSTR および CComBSTR の初期化をするべきでない。
|
118
|
+
|
119
|
+
事前に CComBSTR クラスを用意しているのであれば CComBSTR::Copy を利用する。
|
120
|
+
|
121
|
+
そうでなければ SysAllocString を利用して、値の受け取り側がラッパークラスでなければ各要素で SysFreeString を明示する。
|
122
|
+
|
123
|
+
###宜しければご教示下さい
|
124
|
+
|
125
|
+
素人の検証・見解ですので、内容に相違がある場合はご指摘をお願いします。
|