プログラマ専用SNS ミクプラ

早速ですが質問です

VistaでVC++2008 Express Editionを使っています

コンパイルはできるのですがプログラムを実行すると必ず同じところで止まってしまいます
スムースに動くときもあるので、原因はどこか、少しずつプログラムを変えていたら
スムースに動くときのプログラムに静的変数をひとつでも増やすと同じところで止まってしまうバグが出ています
それ以上静的変数さえ取らなければどんな処理をしてもプログラムは動いてくれます
静的変数をそれ以上取ること自体に問題があるようです
静的変数はどこで取ろうが（メイン関数で取ろうが別の関数で取ろうが）
スムースに動くときのプログラムにひとつでも付け足すとプログラムの実行があるところで中断されてしまいます
静的変数はその変数を使わないでも宣言するだけでバグがでます
まさか静的変数を取れる上限なんてあるわけないと思うのですが、何か考えられることはありますか・・・

単にプログラムのどこかとの相性が悪いだけでしょうか・・・

よろしくお願いします

コードを載せてください。

そうおっしゃられるということはやはりあまり一般的でなくおかしいことなのですね・・・

たしかにコードを公開し、優れた方にデバッグしてもらえば、
原因究明はすばやく済みそうですが、よければ経験から推測してもらえないでしょうか
まずは与えられた助言から自分で何とかしてみたいと思っています

勝手は承知ですが御寛恕願います

> よければ経験から推測してもらえないでしょうか

あくまで予測ですが、スタックオーバーフローが原因ではないでしょうか。
スタック領域を増やしてみては？

こんなに身勝手に質問しているのにご回答ありがとうございます

プログラムの動き的にそうかもしれません

心当たりあるところがあるので調べてみます

御津凪さんからの助言をもとにスタックサイズを変更してみました
プロジェクトのプロパティ→リンカ→システムで最初スタックサイズが0だったので
20MByteまで増やして実行してみましたがだめなようです

不思議な点としては、調べたところスタックサイズはデフォルトでは1MByteだということですが自分のは0だったことです
これおかしいのでしょうか・・・

ただ、スタックオーバーフロー、調べてみると、どうも自分のプログラムはその条件に似通ってるんですよね
サブルーチン内でわりと大きい配列取ってたり、無限ループはしてないけれども、比較的長いループをやってたり

一度、プログラムが暴走してVistaのセキュリティが反応したんですけど（システムに上書きされないように強制終了しました的な）、こういうことから何かわかりますかね・・・
調べているうちにそれこそスタックオーバーフローっぽいなぁって思ったんですけど

最初が0だったので、どれくらい大きくスタックサイズを取ったらいいかもわからず
20MByte程度でやめといたんですがどれくらいを指標にしたらいいんでしょう
これくらい取ってもプログラムが不正終了するなら別なところが原因かも・・・っていう基準値みたいなのありますか

　止まった時の直接的な原因は何なのでしょう（OSが何故そこで止めたのか、です）？
　又、その止まったときの情報は何かありませんか？

　全コードは提示できなくても、その停止したときの詳細情報があれば何かしら
推測を立てやすいのですが、今のままではただの当てずっぽうでしかないので、
解決までに時間がかかってしまいます。


　で、当てずっぽうで話をしますが、何らかの（メモリ配置に起因する）
潜在的なバグが有って、静的変数の数に関係なく今まで偶然動いていただけ
なのかもしれません。

　現時点での情報からできることは、ポインタ系や配列など、
特に「サブルーチン内でわりと大きい配列」を使っているところで
用意した領域以上にプログラムがアクセスをしていないかを調べてみて下さい。

　その他、ビルド時の設定で、バッファセキュリティチェックと
ランタイムチェックを有効にしてビルド・実行してテストすることと
あとは、malloc/newなどを多用しているのであれば、
ttp://msdn.microsoft.com/ja-jp/library/5at7yxcs(VS.80).aspx
の関数を使ってヒープの整合性チェックをするのもいいかと思います。



＞これくらい取ってもプログラムが不正終了するなら別なところが
＞原因かも・・・っていう基準値みたいなのありますか

　1MBもあれば普通は十分です。むしろ多すぎるくらいです。

どれだけ状況を詳しく書かれても、
どのように修正すればよいかは
ソースコードを見ないとたぶんわからないです。

ソースコードを開示していただけない現状では、
いくらやりとりしても解決に至らないと思います。
少なくとも私には無理です。

しかし、世の中には、ソースコードを見なくても
問題を解決できる人がいるかもしれません。その人に期待してください。

>わりと大きい配列

この配列の宣言を見せてください。型が構造体などの場合、sizeof(型)も見せてください。

スタックオーバーフローについてもう少し調べてみたところよく起こる状況として再起関数を使っているときが
主なようですが自分のプログラムには再起処理はどこにも実装してないのでしばらく悩んでいました

Justyさん
＞止まった時の直接的な原因は何なのでしょう（OSが何故そこで止めたのか、です）？
＞又、その止まったときの情報は何かありませんか？
不正終了したときは動作が停止しましたとだけしかOSからメッセージが返ってこず、よくわかりません

＞で、当てずっぽうで話をしますが、
御津凪さんもですが、自分の身勝手に付き合っていただき本当ありがとうございます

＞何らかの（メモリ配置に起因する）
＞潜在的なバグが有って、静的変数の数に関係なく今まで偶然動いていただけ
＞なのかもしれません
ここまでくると、もう自分の力では解決できないように思います

＞用意した領域以上にプログラムがアクセスをしていないかを
サブルーチン内のわりと大きな配列は2次元配列ですがそれでも200*2程度です
さらにその配列は静的に宣言しており、初期値を与えてあります
その配列を上書きするようなことはありませんのでバッファオーバーフローのようなことはないと思います

＞その他～
確認してみましたが、初期設定の状態で、おっしゃられている状態になっており、きちんとビルドしているようです
また、ヒープからのメモリ確保は行っておらず（というかやり方がわからない）、mallocもせいぜい1,2箇所、
プログラムも700行程度です
分割コンパイルは行っていません（これもやり方がわからない）

＞1MBもあれば普通は十分です。むしろ多すぎるくらいです
しっかりとコーディングできていればそうなのですね・・・


boxさん
おっしゃられていることはごもっともだと思います
さらに、もう少し具体的に問題を挙げられればいいものを、
そうできない自分自身の力のなさも重々承知のうえ、このように身勝手な質問をし、
さらにお付き合いいただいていることにはもう本当に申し訳なく、と同時に（それでもご回答いただき）ありがたく思っています。

＞ソースコードを開示していただけない現状では、
＞いくらやりとりしても解決に至らないと思います。
助言をもとに自身で尽力し、それでどうしようもないなら
（そのときまだお付き合いいただけるかは当然別な問題でありますが）、
コードをいくらか綺麗にしたあと公開しようかと思います

tkmakwins15さん
＞この配列の宣言を見せてください。型が構造体などの場合、sizeof(型)も見せてください。

const static TCHAR ref[80][2] = {TEXT("あ"),.....,TEXT("ん")};

とし、後は同様な宣言を他に3つ行っています

あまり参考にならないと思いますが、追加でわかったことを書きます

staticと宣言すれば型はなんであろうが(int, double, HANDLE etc...)、
プログラム実行時は不正終了します

デバッグモードでビルドするとこの症状がでますが
リリースモードでビルドすると症状は回避できます

デバッグモードとリリースモードのビルド時の設定はランタイムライブラリをマルチスレッドデバッグDLLにするか
マルチスレッドにするかの違いだけです

＞不正終了したときは動作が停止しましたとだけしかOSからメッセージが返ってこず、よくわかりません

　えーと、VisualStudioで作っているのですよね？
　デバッガからは何か情報は得られないのでしょうか？



＞const static TCHAR ref[80][2] = {TEXT("あ"),.....,TEXT("ん")};

　ん？
　ref[80][3]の間違いでは？

原因が分かりましたよ。
TEXT("あ")を展開すると…
#ifdef UNICODE
#define TEXT(Q) L##Q
#else
#define TEXT(Q) Q
#endif
なので、もしUNICODEが定義されていない(TCHARをcharとして扱う)ならば、
char ref[2]="あ";//簡略化します。
という宣言をしていることになりますが、VCであれば、ひらがなは2バイトとして扱われますから、
"あ"
は、終端の\0も含めて3バイト必要です。

ですから、

const static TCHAR ref[80][2] = {TEXT("あ"),.....,TEXT("ん")};

は、

const static TCHAR ref[80][3] = {TEXT("あ"),.....,TEXT("ん")};

である必要があります。

＞原因が分かりましたよ。

　多分書きミス、しただけだと思いますよ。
　領域が足りないとコンパイルエラーになるんで。

> VCであれば、ひらがなは2バイトとして扱われますから、
> "あ"
> は、終端の\0も含めて3バイト必要です。

C++ならそうですが、Cなら2バイトで済みます。

Justyさん
＞えーと、VisualStudioで作っているのですよね？
＞デバッガからは何か情報は得られないのでしょうか？
Visual C++ 2008 Express Editionで開発しています
デバッグして実行、のことですか
リソースファイルがあるのですがデバッグして実行すると
リソースファイルが読まれず、よくわからないので、Debugフォルダに出来た実行ファイルを実行しています

＞ref[80][3]の間違いでは？

＞多分書きミス、しただけだと思いますよ
すみません、書きミスではないです、プログラムに実際にそのように記述しています
また、コンパイルは2バイトでも通ったようです


tkmakwins15さん
詳しい解説ありがとうございます
ご指摘されたことをもとに当箇所とそれに付随するところを修正しましたが、改善されませんでした


たかぎさん
＞C++ならそうですが、Cなら2バイトで済みます。
ご指摘のとおり自分はプログラムは .c で作成しています

＞また、コンパイルは2バイトでも通ったようです
＞すみません、書きミスではないです、プログラムに実際にそのように記述しています

　すみません、勝手に C++だと思っていました。



＞リソースファイルが読まれず、よくわからないので、Debugフォルダに出来た実行ファイルを実行しています

　リソースファイルというのは、外部ファイルとしてアプリから読み込む
ファイルのことでしょうか？

　であればそのリソースファイルを slnファイルと同じディレクトリに配置するか、
プロジェクトのプロパティで「構成プロパティ -> デバッグ」の中の
「作業ディレクトリ」にリソースファイルのある場所を指定して下さい。
（slnファイルのある場所からの相対パスか、絶対パスで）

　これで普通にデバッグで実行できるようになるはずなので、
止まったときに何かしらの情報を得られると思います。

結局ソースを提示しなければまともな回答は得られないと思います。
一番可能性が高いのは、バッファオーバーランかポインタ演算を間違って変なところを破壊しているのが原因ではないかと思います。
たまたま動いていたものが、静的変数をひとつでも増やすとメモリ配置が変わって、問題が顕在化するのでしょう。

あと、マルチスレッドとかだと、もっといろいろな原因が考えられます。

たかぎさん
＞一番可能性が高いのは、バッファオーバーランかポインタ演算を間違って変なところを破壊しているのが原因ではないかと思います。
＞たまたま動いていたものが、静的変数をひとつでも増やすとメモリ配置が変わって、問題が顕在化するのでしょう。
なるほど
そういった問題があるのですね
何度もやったのですが、今一度プログラムを順をおって見ていき、だめそうなら（だめだろうけど）、
ある程度綺麗にしてソースを公開しようと思います

＞あと、マルチスレッドとかだと、もっといろいろな原因が考えられます。
スレッド数は少ないですが（プロシージャともうひとつ）、マルチスレッドです（泣

Justyさん
初めてデバッグして実行をしたので読み解くのに時間かかりました（結局読み解けませんでした）

そして、参考になるかわかりませんが、不正終了時に以下のようなメッセージが出ています

MyGame.exeの 0x629c6a83 でハンドルされていない例外が発生しました: 0xC0000005: 場所 0x535ba25c を読み込み中にアクセス違反が発生しました。

とりあえず、デバッグして実行を覚えたので、できるかぎり自分でがんばってみようと思います

＞MyGame.exeの 0x629c6a83 でハンドルされていない例外が発生しました:
＞0xC0000005: 場所 0x535ba25c を読み込み中にアクセス違反が発生しました

　おかしなところで、おかしなメモリを読みにいって落ちているように見えますね。
　
　可能性はいろいろありますが、一番高そうなのがスタックを破壊していることです。
　例えばローカル変数の配列をオーバーして書き込みをするとよく起こります。

　もしそうだとすれば、確実ではないですが基本ランタイムのチェックを有効にして
ビルド・実行すれば見つけられる可能性があります。

　もしよければお試し下さい。



＞できるかぎり自分でがんばってみようと思います

　頑張って下さい！

Justyさん
＞可能性はいろいろありますが、一番高そうなのがスタックを破壊していることです。
＞例えばローカル変数の配列をオーバーして書き込みをするとよく起こります

まさにこの通りだったのかと思います
デバッグしながら実行すると、どこが悪かったか矢印がでるのですね
最初は下にあるメモリ番地ばかり見ていてわけがわかりませんでしたが
プログラムを見てみると左側にちょこんと矢印が出ていました

そこを確認したところあまりよく理由はわかっていないのですが
どうも散々指摘されていたバッファオーバーランのようで、配列を大きく取ると症状は改善されました

構造体にメンバを4つ用意しておりそのメンバを、ひとつの配列につなげて格納したく、
wcscat_sを使ってつなげていたのですが、格納先の配列をconcMember[50]とすると

// ダメなプログラム
struct _tagPageInfo {
	TCHAR content1[10];
	TCHAR content2[10];
	TCHAR content3[10];
	TCHAR content4[10];
} PageInfo;

PageInfo *page;
<中略>
(関数内部)
	TCHAR concMember[50];

	wcscat_s(concMember, 50, page->content1);
	wcscat_s(concMember, 50, page->content2);
	wcscat_s(concMember, 50, page->content3);
	wcscat_s(concMember, 50, page->content4);
<以下省略>
// ダメなプログラムここまで

// 変更してとりあえず動いてるプログラム
<省略>
(関数内部)
	TCHAR concMember[200];

	wcscat_s(concMember, 50, page->content1);
	wcscat_s(concMember, 50, page->content2);
	wcscat_s(concMember, 50, page->content3);
	wcscat_s(concMember, 50, page->content4);
<以下省略>

としていて、メンバはひとつが大きさ10なので50あればいいだろうと思っていたのですがだめだったようです

また、上記のようなことができるならこうすればいいのかと以下を試してみましたが

// 変更してもダメなプログラム
<省略>
(関数内部)
	TCHAR concMember[50];

	wcscat_s(concMember, 10, page->content1);
	wcscat_s(concMember, 10, page->content2);
	wcscat_s(concMember, 10, page->content3);
	wcscat_s(concMember, 10, page->content4);
<以下省略>

これはだめでした

concMemberを200にするととりあえずは改善されたのですが、これは、根本的な解決法になっているでしょうか
（なっていないような気がする）

しかし実際に、メンバの大きさは10で、つないでもせいぜい40なので200もいらず、少し不恰好な状況です

普通、このように文字列をつなぎたい場合、どういったプログラムを組むことが理想なのですか

とりあえず、質問のバグに関して症状が（一時的であるかもしれないけれども）改善されたので、ご報告と思いまして

msdnのリファレンスから引用

＞errno_t wcscat_s(
＞ wchar_t *strDestination,
＞ size_t numberOfElements,
＞ const wchar_t *strSource
＞);
＞
＞パラメータ
＞strDestination
＞null で終わる追加先の文字列バッファ。
＞
＞numberOfElements
＞追加先の文字列バッファのサイズ。
＞
＞strSource
＞null で終わる元の文字列バッファ。
＞
＞ 戻り値
＞正常終了した場合は 0 を返します。失敗した場合はエラー コードを返します。

第３引数は、間違いなく'\0'で終端しているでしょうか？
また、戻り値はいくつでしょうか？
調べてみてはいかがでしょう。

boxさん
ご回答ありがとうございます

＞第３引数は、間違いなく'\0'で終端しているでしょうか？
＞また、戻り値はいくつでしょうか？
一応、第3引数は終端文字は入っているようです
戻り値も正しいようです

変更してもダメなプログラムの方をデバッグしながらメモリの状態を確認していたのですが
どうも配列をある一定の大きさ以下にとるとおかしくなるようです

おかしくなるとは、concMemberは書き忘れましたがstaticで宣言していて、後の方で
for(j=0;j<200;j++) concMember[j] = 0;
と、リフレッシュ？している（つもり）のですが、どうもこれが配列をある一定の大きさ以下にとると
完全にリフレッシュされないまま
（ちょうどこの問題の関数のところはもうひとつのスレッドに依存しているので）新たなPageInfo構造体のメンバがやってくるようです

ある大きさ以上、ならリフレッシュ処理が追いついていないのかと疑うつもりでしたが
ある大きさ以下（この場合concMember[200]ではいいのですが[50]はダメなので）、なので原因を追求しています

手っ取り早く済ますには別なところで処理するか
つなぎ方をかえたりしたほうがいいのかといろいろ模索しています

こんばんは

デバッグにハマっています

デバッグのやり方を覚えたので、手探りでですがいろいろと試しているところです
デバッグをしながらコードを見つめなおすことで新しい発見があったりしているので、
今のところ、自分の力だけでもずいぶん出来ることが増えました

以前はプログラムを走らせて異常があればプログラムを一から全部見直していたので、
何度もコードを変えたりしてそれでもダメで疲れ果ててしまっていたのですが、
デバッガの力を借りることである程度持久力がついてきました

質問の件は、上述したとおりまだまだ自分で出来ることがあるので、しばらく様子を見させてください
出来ることをやってそれでもダメならまた質問させてもらいます

今回、ご助力くださったみなさま、すごく親切にしていただき、嬉しかったです
ありがとうございました
特にデバッグのやり方を教えてくれたJustyさんには深く感謝しています
ありがとうございました

たぶんまた質問にくるので、そのときはよろしくお願いします

スレッドを全部読んではいないので、
同じアドバイスを受けているかもしれませんが、、、

原因と結果を勘違いしないように。

『「静的変数を追加」をするかしないかで、
実行時エラーが発生したりしなかったりする』

という結果の認識はまぁ良いのですが、
原因を「静的変数を追加」だけに求めるのは早計です。
別の所に原因があって、「静的変数を追加」することにより、
それが発覚するのかもしれません。

件の静的変数は残しておいて、プログラムの他の部分を削るとどうなるでしょうか？

マウスによる選択を作ったのですが、二箇所目を作るとフリーズします。
何故でしょうか？

#include "DxLib.h"
#include <stdio.h>


typedef struct{
int x;
int y; //座標
int WheelRotVol;//ホイールの回転量
unsigned int Button[8]; //ボタンの押した状態
}Mouse_t;
Mouse_t Mouse;

int GetHitMouseStateAll_2(Mouse_t *Nezumi){
if(GetMousePoint( &Nezumi->x, &Nezumi->y ) == -1){ //マウスの位置取得
return -1;
}
int MouseInput=GetMouseInput(); //マウスの押した状態取得
for(int i=0; i<8; i++){ //マウスのキーは最大8個まで確認出来る
if( (MouseInput & 1<<i ) != 0 ) Nezumi->Button++; //押されていたらカウントアップ
else Nezumi->Button = 0; //押されてなかったら0
}
Nezumi->WheelRotVol = GetMouseWheelRotVol() ; //ホイール回転量取得
return 0;
}


以下メインでの選択画面
SetMouseDispFlag( TRUE ) ;//マウス表示オン
while(b==0){
//↑メッセージ処理 　 ↑画面をクリア 　　　　　　↑ESCが押されていない

GetHitMouseStateAll_2(&Mouse); //マウスの入力状態取得

/* DrawFormatString(0,0,White,"座標[%d,%d],回転量:%d,",Mouse.x,Mouse.y,Mouse.WheelRotVol);

for(int i=0; i<8; i++){
DrawFormatString(0, 20+20*i, White, "ボタン%d:%u", i, Mouse.Button);
}*/
if(Mouse.x>50 && Mouse.x<150 && Mouse.y>350 && Mouse.y <365 && Mouse.Button[0]> 1){
change_card[0]=1;
DrawBox( 50,350 , 150 , 365 , BoxCr , TRUE ) ;
DrawFormatString(50,350, Ano, "HOLD 1：" );
}
if(Mouse.x>170 && Mouse.x<270 && Mouse.y>350 && Mouse.y <365 && Mouse.Button[0]> 1){
change_card[1]=1;
DrawBox( 170,350 , 270 , 365 , BoxCr , TRUE ) ;
DrawFormatString(170,350, Ano, "HOLD 2：" );
}
if(Mouse.x>290 && Mouse.x<390 && Mouse.y>350 && Mouse.y <365 && Mouse.Button[0]> 1){
change_card[2]=1;
DrawBox( 290,350 , 390 , 365 , BoxCr , TRUE ) ;
DrawFormatString(290,350, Ano, "HOLD 3：" );
}
if(Mouse.x>410 && Mouse.x<510 && Mouse.y>350 && Mouse.y <365 && Mouse.Button[0]> 1){
change_card[3]=1;
DrawBox( 410,350 , 510 , 365 , BoxCr , TRUE ) ;
DrawFormatString(410,350, Ano, "HOLD 4：" );
}
if(Mouse.x>530 && Mouse.x<630 && Mouse.y>350 && Mouse.y <365 && Mouse.Button[0]> 1){
change_card[4]=1;
DrawBox( 530,350 , 630 , 365 , BoxCr , TRUE ) ;
DrawFormatString(530,350, Ano, "HOLD 5：" );
}
if(Mouse.x>200 && Mouse.x<300 && Mouse.y>380 && Mouse.y <395 && Mouse.Button[0]> 1){
DrawFormatString(200,380, White, "Clear" );
DrawBox( 50,350 , 150 , 365 , BoxCr , TRUE ) ;
DrawFormatString(50, 350, White, "card %d：" , 1 );
DrawBox( 170,350 , 290 , 365 , BoxCr , TRUE ) ;
DrawFormatString(170,350, White, "card %d：" , 2 );
DrawBox( 290,350 , 410 , 365 , BoxCr , TRUE ) ;
DrawFormatString(290,350, White, "card %d：" , 3 );
DrawBox( 410,350 , 510 , 365 , BoxCr , TRUE ) ;
DrawFormatString(410,350, White, "card %d：" , 4 );
DrawBox( 530,350 , 630 , 365 , BoxCr , TRUE ) ;
DrawFormatString(530,350, White, "card %d：" , 5 );
for(i=0;i<5;){
change_card=0;
i=i++;
}
}
ここがおかしい if(Mouse.x>438 && Mouse.x<520 && Mouse.y>380 && Mouse.y <395 && Mouse.Button[0]> 1){
b=1;
}
ScreenFlip();
}


この部分でマウスをクリックすると固まります。
但し一回だけしかマウス選択を行わなければ問題ありません。

よろしくお願いします。

まず規約を読んでください。
字下げ、プレタグ等がされていません。

あと、コードが断片すぎて分かりません。
>以下メインでの選択画面
以下のコードは何ですか？関数ではありませんよね？
bというのも変数宣言されていません。
まず、コンパイルの通ったコードからの関数を抜粋し、適宜説明を加えてください。

＞i=i++;

　ここは怪しいです。
　結果が不定になるので、問題の原因にもなり得ます。

　しかし、雰囲気的にクリックしているところも違うので、多分原因とは違うのでしょう。
　正直これだけの情報ではわからないので、周辺のコードも含めて
公開した方がいいのかもしれません。

断片コードからの推測です。

while(b==0) の中で ScreenFlip(); 等の更新処理を行っていませんか？
b=1; になると、 ScreenFlip(); が含まれている while(b==0) ブロック内に入ることにならず（ ScreenFlip されず）、
画面が固まったように見えるのでは？

そうでないのなら、これ以上は本当に分からない（記載箇所以外に問題がある可能性がある）ので、
規約を守りつつ、全体のコードを提示するか添付してください。

妄想によって補完してみました。
一応動く形にまとめてみましたが、これはどうなれば想定していた結果になりますか？