混合モードC ++/CLIクラッシュ:ATEXITのヒープ腐敗(静的破壊者登録)
質問
私はプログラムの展開に取り組んでおり、コードベースはC ++/CLIとC#の混合物です。 C ++/CLIにはすべてのフレーバーがあります:ネイティブ、混合(/clr
)、および安全(/clr:safe
)。私の開発環境では、すべてのC ++/CLIコードのDLLを作成し、C#コード(EXE)からそれを参照しています。この方法は完璧に機能します。
単一の実行可能ファイルをリリースしたいリリースについては(「なぜDLLとexeを分離していないのか」と述べています。
これまでのところ、私はすべての異なるソースでEXEをコンパイルすることに成功しました。ただし、実行すると、オンライン、閉鎖、デバッグをチェックするオプションを備えた「XXXXが機能しなくなった」ダイアログを取得します。問題の詳細は次のとおりです。
Problem Event Name: APPCRASH
Fault Module Name: StackHash_8d25
Fault Module Version: 6.1.7600.16559
Fault Module Timestamp: 4ba9b29c
Exception Code: c0000374
Exception Offset: 000cdc9b
OS Version: 6.1.7600.2.0.0.256.48
Locale ID: 1033
Additional Information 1: 8d25
Additional Information 2: 8d25552d834e8c143c43cf1d7f83abb8
Additional Information 3: 7450
Additional Information 4: 74509ce510cd821216ce477edd86119c
デバッグしてVisual Studioに送信すると、次のように報告されています。
Unhandled exception at 0x77d2dc9b in XXX.exe: A heap has been corrupted
BREAK結果を選択すると、追加情報なしでntdll.dll!77d2dc9b()で停止します。 Visual Studioに継続するように指示すると、プログラムは正常に起動し、おそらくデバッガーが添付されているため、問題なく機能しているようです。
これをどう思いますか?このヒープの腐敗を避けるにはどうすればよいですか?これを除いて、プログラムは正常に機能しているようです。
私の要約コンピレーションスクリプトは次のとおりです(Brevityのエラーチェックを省略しました):
@set TARGET=x86
@set TARGETX=x86
@set OUT=%TARGETX%
@call "%VS90COMNTOOLS%\..\..\VC\vcvarsall.bat" %TARGET%
@set WIMGAPI=C:\Program Files\Windows AIK\SDKs\WIMGAPI\%TARGET%
set CL=/Zi /nologo /W4 /O2 /GS /EHa /MD /MP /D NDEBUG /D _UNICODE /D UNICODE /D INTEGRATED /Fd%OUT%\ /Fo%OUT%\
set INCLUDE=%WIMGAPI%;%INCLUDE%
set LINK=/nologo /LTCG /CLRIMAGETYPE:IJW /MANIFEST:NO /MACHINE:%TARGETX% /SUBSYSTEM:WINDOWS,6.0 /OPT:REF /OPT:ICF /DEFAULTLIB:msvcmrt.lib
set LIB=%WIMGAPI%;%LIB%
set CSC=/nologo /w:4 /d:INTEGRATED /o+ /target:module
:: Compiling resources omitted
@set CL_NATIVE=/c /FI"stdafx-native.h"
@set CL_MIXED=/c /clr /LN /FI"stdafx-mixed.h"
@set CL_PURE=/c /clr:safe /LN /GL /FI"stdafx-pure.h"
@set NATIVE=...
@set MIXED=...
@set PURE=...
cl %CL_NATIVE% %NATIVE%
cl %CL_MIXED% %MIXED%
cl %CL_PURE% %PURE%
link /LTCG /NOASSEMBLY /DLL /OUT:%OUT%\core.netmodule %OUT%\*.obj
csc %CSC% /addmodule:%OUT%\core.netmodule /out:%OUT%\GUI.netmodule /recurse:*.cs
link /FIXED /ENTRY:GUI.Program.Main /OUT:%OUT%\XXX.exe ^
/ASSEMBLYRESOURCE:%OUT%\core.resources,XXX.resources,PRIVATE /ASSEMBLYRESOURCE:%OUT%\GUI.resources,GUI.resources,PRIVATE ^
/ASSEMBLYMODULE:%OUT%\core.netmodule %OUT%\gui.res %OUT%\*.obj %OUT%\GUI.netmodule
更新1
これをデバッグシンボルでコンパイルし、再試行すると、実際にはより多くの情報を取得します。コールスタックは次のとおりです。
msvcr90d.dll!_msize_dbg(void * pUserData, int nBlockUse) Line 1511 + 0x30 bytes
msvcr90d.dll!_dllonexit_nolock(int (void)* func, void (void)* * * pbegin, void (void)* * * pend) Line 295 + 0xd bytes
msvcr90d.dll!__dllonexit(int (void)* func, void (void)* * * pbegin, void (void)* * * pend) Line 273 + 0x11 bytes
XXX.exe!_onexit(int (void)* func) Line 110 + 0x1b bytes
XXX.exe!atexit(void (void)* func) Line 127 + 0x9 bytes
XXX.exe!`dynamic initializer for 'Bytes::Null''() Line 7 + 0xa bytes
mscorwks.dll!6cbd1b5c()
[Frames below may be incorrect and/or missing, no symbols loaded for mscorwks.dll]
...
これを「引き起こす」という私のコードの行(ダイナミックイニシャルイザー Bytes::Null
) は:
Bytes Bytes::Null;
次のように宣言されているヘッダーで
class Bytes { public: static Bytes Null; }
また、ヘッダーでグローバルな外部をやってみました。
extern Bytes Null; // header
Bytes Null; // cpp file
同じ方法で失敗しました。
CRTのようです atexit
関数は責任があり、静的初期化のために不注意に必要です。
修理
Ben VoigtがCRT関数(ネイティブの静的初期化剤を含む)の使用を指摘したように、CRTの適切な初期化が必要です(これはで発生します mainCRTStartup
, WinMainCRTStartup
, 、 また _DllMainCRTStartup
)。 C ++を備えた混合C ++/CLIファイルを追加しました main
また WinMain
:
using namespace System;
[STAThread] // required if using an STA COM objects (such as drag-n-drop or file dialogs)
int main() { // or "int __stdcall WinMain(void*, void*, wchar_t**, int)" for GUI applications
array<String^> ^args_orig = Environment::GetCommandLineArgs();
int l = args_orig->Length - 1; // required to remove first argument (program name)
array<String^> ^args = gcnew array<String^>(l);
if (l > 0) Array::Copy(args_orig, 1, args, 0, l);
return XXX::CUI::Program::Main(args); // return XXX::GUI::Program::Main(args);
}
これを行った後、プログラムはもう少し進んでいますが、それでも問題があります(他の場所で対処されます):
- プログラムがC#のみである場合、C ++/CLIメソッドを呼び出し、C ++/CLIプロパティを取得し、管理されたC ++/CLIオブジェクトを作成するときはいつでも正常に機能します。
- C#によってC ++/CLIコードに追加されたイベントは、発火することはありません(そうすべきであっても)
- もう1つの奇妙なエラーは、例外が発生することであるということです。xからxにキャストできないという無効なCaStexception(xはxと同じです...)
ただし、ヒープの破損は(CRTを初期化することにより)固定されているため、質問が行われます。
正しい解決策はありません