構造を変更した後にアプリケーションがクラッシュする

Question

okをコンパイルするプロジェクトで問題が発生しましたが、起動時にクラッシュしてInitInstance（）に到達しました。 私は構造体に文字列を追加した後、この問題が発生した：私は、構造体の最後のメンバーを追加すると

typedef struct 
{ 
long   nChannelIndex; 
TCHAR   szChannelName[32]; 
DWORD   dwStartTime;  // time_t 
DWORD   dwPlaytimeMs;  // msecs 
TCHAR   szStepName[32]; 
TCHAR   szFilename[MAX_PATH]; 
long   nLenMs; 
TCHAR   szStepDescr[64]; 
DWORD   dwSessionID; 
TCHAR   szLocationName[32]; 
long   bInsertion; 
BOOL   nOrigin;  // 0= local, 1= cuemaster, 
TCHAR   szList[32]; 
TCHAR   szFSPath[MAX_PATH]; << THIS HERE IS THE PROBLEM 
}REPORTDATA, *LPREPORTDATA; 

は問題が始まりました。配列のサイズを小さくすると（例えば12）、アプリケーションは正常に動作します。

私はchkstk.asmにクラッシュを取得 - このコードの前後に：Windows 7の究極の64ビットで、私は32ビットのCをコンパイルしています

; Find next lower page and probe 
cs20: 
sub  eax, _PAGESIZE_   ; decrease by PAGESIZE 
test dword ptr [eax],eax  ; probe page. 
jmp  short cs10 

++アプリケーション。 Msvc 2010.

私は自分のコードをデバッグすることを求めていません。クラッシュを引き起こした原因と発生場所を示すコードを含めるだけです。

すべてのアイデア？ ご協力いただきありがとうございます！

Answer 1

クラッシュが発生するモジュールの名前chkstk.asmは何が起こっているのかを示す手掛かりです。スタック割り当てをチェックして、あなたが不足していないことを確認しています。 にはがあります。構造に大きな新しい要素を追加してください。単一の構造体を持つスタック空間を使い果たすことは非常に難しいので、配列の配列があると仮定します。ローカル変数はスタックに割り当てられるものなので、問題はおそらくこれらの構造の配列を含むローカル変数です。

/F compiler switchを使用すると、プログラムのスタック領域を増やすことができます。

アレイの代わりにvectorを使用することもできます。この場合、スタック上ではなくヒープ内に領域が割り当てられます。

Answer 2

あなたが提供した情報で正確に診断することは不可能ですが、スタックをオーバーフローさせたということはかなり安全です。 Mark Ransomが言っているように、あなたはたぶんスタックのどこかに大きなローカル配列を持っています。

EDIT： ローカル変数は通常は、必ずしも必要ではないが、保存されたスタックは、アプリケーション内の有限の大きさで、それは通常、スレッドが作成されたときに割り当てられ、pthread_attr_setstacksizeのようなOSの機能で設定されている、一つの選択肢であればスタックスペースを使い果たしているのは、あなたが作業しているスレッドのスタックを拡大することですが、通常は良い考えではありません。

問題の最も簡単で安全な解決策は、C mallocまたはC++ newを呼び出してヒープに大きなデータを割り当てることです。ヒープは一般にスタックよりも数桁大きいが、データの処理が完了したら明示的にC freeまたはC++を削除する必要があり、スタック変数のようにローカルスコープが終了してもクリアされません。

ヒープ変数の主な懸案事項は、たとえばスロー経由で早期に終了する関数を通じてリークすることです。このため、std :: unique_ptrを使用して格納するヒープオブジェクトを扱うときは、RAIIのコンセプトに準拠することをお勧めします。