質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.50%
C#

C#はマルチパラダイムプログラミング言語の1つで、命令形・宣言型・関数型・ジェネリック型・コンポーネント指向・オブジェクティブ指向のプログラミング開発すべてに対応しています。

C++

C++はC言語をもとにしてつくられた最もよく使われるマルチパラダイムプログラミング言語の1つです。オブジェクト指向、ジェネリック、命令型など広く対応しており、多目的に使用されています。

Q&A

3回答

18125閲覧

再現性が不安定なヒープ破損について

ibuki

総合スコア15

C#

C#はマルチパラダイムプログラミング言語の1つで、命令形・宣言型・関数型・ジェネリック型・コンポーネント指向・オブジェクティブ指向のプログラミング開発すべてに対応しています。

C++

C++はC言語をもとにしてつくられた最もよく使われるマルチパラダイムプログラミング言語の1つです。オブジェクト指向、ジェネリック、命令型など広く対応しており、多目的に使用されています。

0グッド

1クリップ

投稿2017/09/28 10:14

編集2022/01/12 10:55

###前提・実現したいこと
C++CLIで作成したライブラリをC#から引数を渡して読み込む処理を行っています。
開発したプログラムをC#にて以下のエラーメッセージが発生しました。

###発生している問題・エラーメッセージ
ハンドルされない例外が 0x00007FF939DC775F (ntdll.dll) で発生しました(~.exe 内): 0xC0000374: ヒープは壊れています。 (パラメーター: 0x00007FF939E286B0)

###該当のソースコード

C#

1 int intA = 10; 2 IntPtr WIntPtr1 = new IntPtr(); 3 WIntPtr1 = Marshal.AllocHGlobal(Marshal.SizeOf(intA)); 4 Marshal::StructureToPtr(intA, WIntPtr1, false); 5 int B = CPPLIBRARY.WSetInt(WIntPtr);

###試したこと
調べてみたところ、「不正なメモリアクセスによるヒープ破損」が原因だと見当をつけたのですが、毎回同じ箇所で起こるわけではなく、C++やC#のどっちの処理でも発生したり、次に実行したときは同じ箇所で発生しなかったりします。
プログラム中は、Marshal.AllocHGlobalやMarshal.StructureToPtrで用意したIntPtr変数、またはC++CLI内でgcnewしたリストなどを引数としてC++のライブラリに渡す処理を数十個ほど行っているのでそのせいかなとは思うのですが、どうアプローチしていいかわかりません。
これが何故起こったり起こらなかったりするのか、解決するためにはどうしたらいいか、解決方法や原因をどう調べたらいいでしょうか。

###補足情報(言語/FW/ツール等のバージョンなど)
環境はWindows10のVSCommunity2017Ver15.2です。

C++CLIでの実際のエラーは、例えばこんなふうに構造体のリストをgcnewで作るとき等です
イメージ説明

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

guest

回答3

0

とりあえずApplication Verifierを使ってみたらどうでしょうか?
C++/CLIでどの程度有効か分かりませんが不適切なHeap操作した瞬間を検出できます。

提示されている画像のエラーはすでにヒープが壊されていて壊されたヒープを使用してメモリ確保をしようとしたからエラーになっているのだと思います。
その状態から実際にヒープを壊した場所を見つけるのは困難です。
Application Verifierを使用するとHeapを壊した瞬間にDebugBreakするのでどこで壊したかを特定できたりします。
今回のエラーのメッセージからヒープの管理領域が壊されたのだと思います。
であれば、Verifierで特定できる可能性が高いです。

投稿2017/09/28 12:32

編集2017/09/29 11:13
hmmm

総合スコア818

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

ヒープメモリの破損の検出されたコードと、実際にヒープメモリを壊したコードの場所は異なる場合があります。そのため原因となっている場所を特定するのは非常に困難です。コードを地道に精査するか、ヒープダンプを頻繁にとって精査するか、設計レベルで保証する方法を考えるか、と言ったことになります。

怪しい部分を別プロセス化して、設計レベルで保証するのが一番お手軽です。ですが、本質的な解決ではありませんし、パフォーマンス上のデメリットも大きく、場合によっては現状のコードを大幅に手直しをする事になるので、難しいところですね。

投稿2017/09/30 05:33

Kunihiro_Narita

総合スコア472

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

こんにちは。

gcnewしたリストなどを引数としてC++のライブラリに渡す処理を数十個ほど行っているのでそのせいかなとは思うのですが、どうアプローチしていいかわかりません。

C++/CLIには詳しくないのですが、gcnewで獲得した領域はガベージ・コレクションの対象ということですので、ピュアなC++へ渡すには「ロック」のような操作(コンパクション対象から外す)が必要と思います。C++側でのアクセスがなくなるまで「ロック」されていますでしょうか?

また、きちんとロックしていた場合、C++側で範囲外をアクセスしていないでしょうか?
範囲外アクセスすると落ちてくれることが多いですが落ちる保証があるわけではないので、頑張って虱潰しするしかないように思います。

これが何故起こったり起こらなかったりするのか、

不正な番地へ書き込んだ場合、もしそのメモリが例えばint型変数だった時は、int型変数の値が化けるだけで済みます。もし、多少化けても落ちないような変数であれば発見困難です。
もし、そのメモリがヒープ領域を管理しているところだった場合、ヒープ破壊を検出できる場合があります。その時は観察されている事象が発生すると思います。

gcnewした領域は時にはコンパクションされてメモリ番地が変わります。変わった後の領域が例えばint型変数に割り当てられたり、割り当て前でたまたまヒープ・チェーンを記録しているメモリだったりするでしょう。
そのどちらなのかはコンパクションがいつ起動するかによりますが、これはアプリやシステム全体のメモリの仕様状況に左右されます。
範囲外アクセスの場合も似たような話です。gcnewで確保し、ロックされた領域からの相対で不正アクセスしている筈ですが、そこに何が記録されているのかは、やはりコンパクションやガベージ・コレクションの状況次第です。

解決するためにはどうしたらいいか、解決方法や原因をどう調べたらいいでしょうか。

本質的には設計保証するしかないので、まじでたいへんです。
CRT ライブラリを使用したメモリ リークの検出が使えれば良いのですが、マネージ領域については使えないのではないかと思います。

投稿2017/09/28 11:08

Chironian

総合スコア23272

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

まだベストアンサーが選ばれていません

会員登録して回答してみよう

アカウントをお持ちの方は

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.50%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問