DLLコールのヒープ/スタック破損

Question

Codeblocks（mingwの下でGCCを使用する）内でVisual Studio 2008 SP1で作成されたdll（共通言語ランタイムサポートが有効）を使用しようとしています。 dllに渡されている引数の一部は、呼び出し関数によって動的に割り当てられています。私の質問は次のとおりです：

"dllに渡される引数は、呼び出し元関数のヒープにありますか？これは安全ですか？"

dllから戻ってくると、呼び出し元の関数のスタックが破損し、それらにアクセスしようとすると、この問題をデバッグしようとするとcodeblocks内にSIGTRAPが発生します。

この理由は何ですか？

DLL関数のプロトタイプは次のようなものです。以下に示すように

int __cdecl myTesseractOCR(myOCRData* labels_for_ocr); 

myOCRDaata定義は次のとおりです。すべてのように呼び出し元の関数のヒープ上にあるデータへ

typedef struct __ocr_data 
{ 
    char* arr_image  [NUMOBJ_LIMIT_HIGH]; 
    int start_x   [NUMOBJ_LIMIT_HIGH]; 
    int start_y   [NUMOBJ_LIMIT_HIGH]; 
    int  width    [NUMOBJ_LIMIT_HIGH]; 
    int  height    [NUMOBJ_LIMIT_HIGH]; 
    int  widthstep   [NUMOBJ_LIMIT_HIGH]; 
    char  number_plate_buff [2*NUMOBJ_LIMIT_HIGH]; 
    int  ocr_label_count; 
} myOCRData; 

arr_imageポイント上記の構造の他のメンバは、呼び出し関数のスタック上に存在します。スタックに存在するこれらのメンバーはすべて壊れ、プログラムはSIGTRAPを生成します。私はそのような問題がstackoverflow上のさまざまなスレッドで議論されているのを見ましたが、まだ具体的な解決策を見つけ出していません。

Answer 1

呼び出し側のアプリケーションヒープ上にあるメモリにDLLがアクセスすることは完全に妥当です。あなたがそれを行うことができなかったら、DLLは本質的に役に立たないでしょう。

問題は他の場所にある必要があります。ほとんどの場合、DLLへの呼び出しのパラメータを正しく設定していない可能性があります。

Answer 2

DLLのインターフェイスをというように設定することをお勧めします。可能な限り;すなわち、それらがPODであっても、構造を渡すことを避ける。 2つの異なるコンパイラを使用しているので、これは特に重要です。構造体を渡す場合は、構造体のパッキングが両方のコンパイラの下で明示的に定義されていることを確認してください。

Answer 3

あなたはヒープ関数に属していないGCCおよびDLL大会VS2kSP1 CLR

Answer 4

のための呼び出し規約フラグをクロスチェックできます。モジュールにメモリを割り当て、別のメモリにメモリを割り当てることは、メモリを割り当てたモジュールがそれを解放するものであることを確認するだけで十分です。
問題の第2の原因は、異なる呼び出し変換である可能性があります。エクスポートされたすべての関数の呼び出し規約を指定します。