遅刻の「言い訳」選手権

再帰呼び出しを行うプログラムでスタックオーバーフローが発生するようになりました。

そこで最大スタックサイズを変更しようと考えていますが
最大スタックサイズを大きくすることで何か影響があることはあるのでしょうか?

他アプリ等に影響が出ないかを懸念しています。

※最大スタックサイズは最大で16Mらしく、現在は1Mです。
 特に影響がないのであれば最初から16Mにしておけば良いような気もして疑問に思っています。

A 回答 (5件)

スレッドごとにスタックが確保されるのでプロセスで使用可能な最大スレッド数が減ります


他プロセスへの影響は起こりえません
    • good
    • 0
この回答へのお礼

「他プロセスへの影響は起こりえません」とのこと。
まさに知りたい情報でした。
ありがとうございました。

お礼日時:2008/10/08 20:41

アプリがWindow上でということなら1プロセスに使えるメモリー空間は2GBだったと思います



ヒープやスタックの予約サイズ、コードなどを合計し2GBを超えると起動が出来なくなるのでそのあたりの余裕を少し見たほうがいいように思います

16MBが最大なら10-12MBぐらいにしたほうが
今後、コードの多少の手直しでもスタックサイズをいじらなくてもいいように
    • good
    • 0

念のため確認させてください。



スタックサイズを16Mバイトにすれば、期待通りに動くのでしょうか?
何かのバグで、再帰呼び出しが止まらない可能性もありますので。

この回答への補足

単純に2Mにすれば動くことは確認できています。
バグではない認識です。

補足日時:2008/10/04 18:25
    • good
    • 0

再帰関数に与える引き数が「構造体やオブジェクトの実体渡し」になっていませんか?



また、引き数の数が3個以上になっていませんか?

また、再帰関数の関数内で定義されている変数が多かったり、配列変数を定義していたりはしませんか?

再帰関数の引き数は「int が1つか2つ」にしましょう。

再帰関数の関数内でauto変数を定義する場合は、int変数など、単純変数のみにしましょう。

再帰関数の関数内で「char buf[256];」などのように、文字列操作用のchar配列変数をauto変数で定義してはいけません。

この辺りを改善すれば、スタックは1Mもあれば「余りまくり」です。

この回答への補足

コーディング上の問題は重々承知しおりますが
何せ古いコーディングで大きな改修は難しいのが現状です。

単純にスタックサイズを大きくすることで
”当面”は解決するため、最大スタックサイズ変更の影響を知りたいと思っている次第です。

補足日時:2008/10/04 18:33
    • good
    • 0

1MBで足りなくなる再帰ならロジックを考え直したほうがいいように思います


本当に想定どおりで1MB以上のスタックが必要になるのでしょうか?
ロジック的なバグでいらぬ再帰が掛かっているのではありませんか

この回答への補足

コーディング上の問題は重々承知しおりますが
何せ古いコーディングで大きな改修は難しいのが現状です。

単純にスタックサイズを大きくすることで
”当面”は解決するため、最大スタックサイズ変更の影響を知りたいと思っている次第です。

処理レコード件数が増えると再帰回数が増える作りですので
今後のレコード件数増加を想定してスタックサイズを決定できればと思っています。

補足日時:2008/10/04 19:00
    • good
    • 0

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!

このQ&Aを見た人はこんなQ&Aも見ています


おすすめ情報