C++DLLでGlobalAllocしたメモリをC#のP/Invokeで受け取る際に文字列のマーシャリングをしていると勝手に解放される。

Question

GlobalFreeを実行するとプログラムがクラッシュする場合があり、色々調べた結果、下記サンプルコードの様にGlobalFree相当の解放が勝手に行われているという結論に至りました。

文字列のマーシャリングをしているMallocEx1では「C++処理 MallocEx」というメッセージボックスが出ているときは、プロセスの仮想メモリ使用量(コミットサイズ)が500MiBを超え、「C#処理 MallocEx1呼び出し完了」というメッセージボックスが出るところまで行くと、GlobalFreeしていないのにメモリが勝手に解放されていることをタスクマネージャーなどで確認しました。

MallocEx2のようにマーシャリングをしない場合はメモリが解放されないため、メモリリークして仮想メモリ使用量(コミットサイズ)が増えて1000MiBを超えました。

GlobalAllocしたものが勝手に開放されることに大変驚いたのですが、このような挙動になることはCLRや.NET Frameworkの仕様で決められていることなのでしょうか。

C＋＋DLL側
Visual Studio 2022
WindowsSDK 10.0.22000.0

#include<windows.h>
char* tmp;
void _stdcall MallocEx(int size,int value,char** ppRet) {
	tmp = (char*)GlobalAlloc(GMEM_FIXED, size);
	memset(tmp, value, size );
	MessageBox(NULL,"C++処理 MallocEx","",NULL);
	if (size > 100) {//100文字で頭打ち
		size = 100;
	}
	tmp[size-1] = 0;
	*ppRet = tmp;
}
void _stdcall FreeEx() {
	MessageBox(NULL, "C++処理 FreeEx", "", NULL);
	GlobalFree(tmp);
}

モジュール定義ファイル

LIBRARY
EXPORTS
	MallocEx
	FreeEx

C＋＋DLLを呼び出すC#側
Visual Studio 2022
.NET Framework4.8

using System;
using System.Collections.Generic;
using System.Linq;
using System.Runtime.InteropServices;
using System.Threading.Tasks;
using System.Windows.Forms;
using System.Text;
using System.Text.RegularExpressions;

namespace WindowsFormsApp1 {
	internal static class Program {

		[DllImport("TestDll.Dll",EntryPoint="MallocEx")]
		extern public static void MallocEx1(int size,int value,ref string buff);

		[DllImport("TestDll.Dll",EntryPoint="MallocEx")]
		extern public static void MallocEx2(int size,int value,ref IntPtr buff);

		[DllImport("TestDll.Dll")]
		extern public static void FreeEx();

		[STAThread]
		static void Main() {
			int size = 1024*1024*500;//500MiB確保
			string str1 = null;
			IntPtr str2 = IntPtr.Zero;

			MallocEx1(size,'0',ref str1);
			MessageBox.Show("C#処理 MallocEx呼び出し完了 "+str1);

			MallocEx1(size,'1',ref str1);
			MessageBox.Show("C#処理 MallocEx呼び出し完了 "+str1);

			MallocEx2(size,'0',ref str2);
			MessageBox.Show("C#処理 MallocEx呼び出し完了 "+Marshal.PtrToStringAnsi(str2));

			MallocEx2(size,'1',ref str2);
			MessageBox.Show("C#処理 MallocEx呼び出し完了 "+Marshal.PtrToStringAnsi(str2));

		}
	}
}

Answer 1

ネイティブ相互運用性のベスト プラクティス

❌ 禁止: [Out] string パラメーターを使用しないでください。 文字列がインターン処理された文字列で、文字列パラメーターが [Out] 属性の値で渡された場合、ランタイムが不安定になる可能性があります。 文字列のインターン処理の詳細については、String.Intern のドキュメントを参照してください。

Windows 固有: [Out] 文字列の場合、CLR は文字列を解放するために既定で CoTaskMemFree を使用します。また、UnmanagedType.BSTR とマークされている文字列の場合は SysStringFree を使用します。

これらを踏まえた上で、下のURLの内容を見てください。異なるメモリアロケータでも、実装が同じになるケースは有りえるようで、たまたま違うメモリ解放関数でも解放されただけと推測されます。
CoTaskMemAlloc v malloc v AllocHGlobal

マーシャラーの挙動を完全に理解していたとしても、ネイティブDLL側で確保したメモリを ref string で受けるのは、個人的にかなり怖い作りだなと思います。

既定のマーシャリングの動作

使用しているメモリが CoTaskMemAlloc メソッドで割り当てられていない場合、IntPtr を使用し、適切なメソッドを使用して手動でメモリを解放する必要があります。

とあるので、自分でアロケータを制御する必要があるなら、MSのドキュメントに従ってIntPtrにするか、unsafeで素のポインタを使うのがいいと思います。

Comments

[dn_]

まさに求めていた情報でした。よく読んでみます。ありがとうございます。

Answer 2

(1) DLL の作りがおかしいです。
MallocEx を２回呼び出すと、tmp は置き換わっちゃうのでは？
１回目に呼び出したときに確保したメモリを解放できなくなっちゃいます。
FreeEx のほうはアドレスを渡して解放すべきです。

(2) MallocEx1 が ref string で受けている
ref string で受けるなら、BSTR* を返さないといけないのでは？
BSTR は char* にキャストできますが、その逆はダメだと思います。

(3) １回目の MallocEx1 で string オブジェクト(モドキ)が作成されます。
２回目の MallocEx1 では 別の string オブジェクトが作成され、str1 に格納されますが、１回目の string オブジェクトは参照が切れるので GC が動くと解放されてもおかしくありません。

---

うまくいった組み合わせ

以下の組み合わせでメモリ破壊なく動きました。

[DllImport("SampleDLL.Dll")]
[return: MarshalAs(UnmanagedType.BStr)]
extern public static string StringTest(
    [MarshalAs(UnmanagedType.BStr)] ref string buff);

BSTR WINAPI StringTest(BSTR* ppRet) {
	wchar_t str[] = L"Test!";
	if (*ppRet != nullptr) {
		SysFreeString(*ppRet);
	}
	*ppRet = SysAllocStringLen(str, lstrlen(str));
	return SysAllocStringLen(str, lstrlen(str));
}

---

考察

ref string で渡したとき C# の動きは次のようになっていると思われます。

(1) 文字列を渡すとき、null でなければ BSTR 文字列（MarshalAs で指定された型）を作成し、そのアドレスを dll に渡す
(2) DLL から戻ってきたら返された BSTR から String 文字列を作成し、渡された BSTR は解放する

こう考えると辻褄が合います。

Comments

[KOZ6.0]

２回目の MallocEx1 を別の変数で受ければ解放されないと思いますがいかがでしょう？
もっとも ref string で受けてる時点で怪しいですけどね。

[KOZ6.0]

とてもわかりやすいページがありました。
「BSTRとは？」
https://www.keicode.com/com/bstr-alloc-free.php

[dn_]

>>(1) DLL の作りがおかしいです。
現象を最小コードで再現するサンプルなのでご容赦下さい。
MallocEx を２回呼び出す前に必ずFreeExを呼び出す使用法のイメージです。

>>(2) MallocEx1 が ref string で受けている
>>(3) １回目の MallocEx1 で string オブジェクト(モドキ)が作成されます。
メッセージボックスが表示される度にメモリ使用量を確認すると、２回目の MallocEx1が呼ばれる前にメモリが解放されているため、そもそもマーシャリングでGlobalAllocしたメモリとの関係が切れてると考えています。

[DllImport("TestDll.Dll",EntryPoint="MallocEx")]と文字セットを指定しない場合は
アスキー文字のマーシャリングになっているかと思っていました。

DLL側を
void _stdcall MallocEx(int size,int value, wchar_t** pRet)
とBSTR形式にして、C＃側を
[DllImport("TestDll.Dll",EntryPoint="MallocEx", CharSet = CharSet.Unicode)]
にしてみましたが、同様のメモリ量増減動作となりました。
なおこの時にC＃側を元の
[DllImport("TestDll.Dll",EntryPoint="MallocEx")]
としていると先頭の1文字しかstringに入っていないというおかしな動作でした。

[dn_]

すみません。「BSTR形式にして」と書いてますが、検証したのはBSTR形式ではなくただのwchar_tで、BSTRの先頭に含まれる4バイトのサイズ情報がありませんでした。先頭4バイトを入れて、５バイトからのアドレスを返してBSTR形式の確認をしようと思ったのですが、引数がref stringだとGlobalAllocしたメモリの先頭アドレスを渡さないとプログラムがクラッシュする現象が発生しました。たしかにもし勝手に開放してるなら先頭アドレスを渡さないと解放できないよなと少し納得してしまいました。

また以下のようにSysAllocStringで作ったBSTRをref stringで受けると、プログラムがクラッシュしました。ref stringで何かやってそうなのが関係してるのもかもしれないです。
void _stdcall MallocEx(int size, int value, BSTR* pRet) {
BSTR tmp = SysAllocString(L"aaaaaaaaaa");
*pRet = tmp;
}

[KOZ6.0]

そもそもの目的は何だったのでしょうか？
確実に受け取るのであれば、IntPtr を使えば良いです。
ref string で受け取りたいなら、ワンクッション置いて IntPtr を使えばいいです。
追及するのであれば、引数に MarshalAs 属性をつけて UnmanagedType を指定してみてください。
「MarshalAsAttribute クラス」
https://learn.microsoft.com/ja-jp/dotnet/api/system.runtime.interopservices.marshalasattribute
「UnmanagedType 列挙型」
https://learn.microsoft.com/ja-jp/dotnet/api/system.runtime.interopservices.unmanagedtype

[dn_]

目的はこのような挙動になることがCLRや.NET Frameworkの仕様なのか見識のいる方からご教授頂けないかと思った次第です。実現方法論としてはIntPtrを用いるのが良さそうですね。

[KOZ6.0]

ヒープ領域の string にグローバルメモリ渡して大丈夫？え！渡せちゃう？
不変（immutable) なはずの string を書き換えならまだしも置き換えて挙動がおかしくならないの？
と疑問点ばかりです。
あいまいな知識で回答して申し訳ありません。

[dn_]

検証ありがとうございます。
[MarshalAs(UnmanagedType.BStr)] ref string buffでBSTRを受けれるようになりますね。
無指定だとアスキーなのですから、BSTRで受けるならそう明示的に書かないとダメですよね。
>SysAllocStringで作ったBSTRをref stringで受けると、プログラムがクラッシュしました
というのは当たり前でしたね。

>(1) 文字列を渡すとき、null でなければ BSTR 文字列（MarshalAs で指定された型）を作成し、そのアドレスを dll に渡す
その通りの様ですね。勉強になりました。しかしCLRでメモリ並び変えが実行されたらアドレスが変わりそうな気がしますね。

>(2) DLL から戻ってきたら返された BSTR から String 文字列を作成し、渡された BSTR は解放する
以下のように巨大なBSTRを作ってStringTestを何度も呼び出してみたのですが、
今度は逆にBSTRが解放されていませんでした。。。
SysFreeStringを呼び出してもタスクマネージャー読みでメモリ量が多いままでした。
なんだかもうref stringは使わない方が良い気がしてきました。。。

int size = 1024 * 1024 * 250;
wchar_t *str = (wchar_t*)malloc(size);
int len = size/2-1;
for (int i = 0; i < len ;i++) {
str[i] = L'a';
}
str[len] = L'0';

if (*ppRet != nullptr) {
SysFreeString(*ppRet);
}
*ppRet = SysAllocStringLen(str, lstrlenW(str));

free(str);

[KOZ6.0]

>しかしCLRでメモリ並び変えが実行されたらアドレスが変わりそうな気がしますね。
BSTR はアンマネージメモリに作られるので GC の対象外です。

>今度は逆にBSTRが解放されていませんでした。。。
解放した分、C# 側にメモリが増えてるからでは？
何回かやってみましたが、DLL を抜けるときに一瞬ワーキングセットが 500MB オーバーしてすぐに 270MB くらいに戻りましたよ。

メモリの無駄が多いので使わないほうが良いというのは同感です。

[dn_]

検証ありがとうございます。
マネージドなstringオブジェクトがアンマネージメモリの参照を保持していて大丈夫なのか疑問に思いました。
またstringオブジェクトの参照が無くなったら解放されるのかも疑問でした。(開放されると逆にまずい）
こちらで出てるメモリリークは実行コードの違いかもしれないですね。元の質問から離れて来ているので言及は辞めようと思います。もしかしたら別タイトルで質問を作成するかもしれません。

[KOZ6.0]

String オブジェクトがアンマネージメモリを参照しているわけではないですよ？
管理しているのは、マネージとアンマネージの橋渡しをしているマーシャラーです。
メモリを解放するのも仕様ですね。
この辺、どうなるんだろうと思ってたのですが、私はスッキリしました。

[dn_]

オブジェクトのメモリアドレスをダンプしつつ確認したところ、String オブジェクトがアンマネージメモリを参照しているわけではないことを確認し、かつC# 側のマネージドにメモリが増えており、繰り返し実行しているうちに遅れて解放されていることを確認しました。しかしC#側でなぜかstring変数へnullを代入してから、GC.Collect()を実行しないと全然解放されないと、それでも微妙にリークしてるような感じはあるんですが保留とします。
お付き合い頂きありがとうございました。