c++ - Linuxのプロセスのスタックサイズに制限はありますか？

Question

Linuxのプロセスのスタックサイズに制限はありますか？それは単にマシンのRAMに依存しているのでしょうか？

関数への再帰呼び出しの深さを制限するために、これを知りたいです。

Answer 1

スタックは通常、リソース制限によって制限されます。次を使用して、インストールのデフォルト設定を確認できますulimit -a。

stack size              (kbytes, -s) 8192

（これは私のものが8MBであることを示しています。これは巨大です）。

この制限を削除または増やすと、マシン内のすべてのRAMをスタックに使用できなくなります。スタックはプロセスのアドレス空間の最上部近くのポイントから下向きに成長し、ある時点で実行されます。コード、ヒープ、またはロードされたライブラリに。

Answer 2

制限は管理者が設定できます。

manulimitを参照してください。

おそらく、越えられないデフォルトがあります。スタックの制限について心配する必要がある場合は、デザインを再考する必要があると思います。おそらく反復バージョンを作成しますか？

Answer 3

これは、使用しているアーキテクチャ（32ビットまたは64ビット）と、マルチスレッドであるかどうかに大きく依存します。

デフォルトでは、シングルスレッドプロセス、つまりexec（）時にOSによって作成されるメインスレッドでは、スタックは通常、アドレス空間内の他の何かに到達するまで増大します。これは、32ビットマシンでは、たとえば1Gのスタックを持つことが一般的に可能であることを意味します。

ただし、これはマルチスレッドの32ビットプロセスには当てはまりません。マルチスレッドプロセスでは、スタックはアドレススペースを共有するため、割り当てる必要があります。そのため、通常、スタックには少量のアドレススペース（1Mなど）が割り当てられ、アドレススペースを使い果たすことなく多くのスレッドを作成できます。

したがって、マルチスレッドプロセスでは、それは小さくて有限です。シングルスレッドプロセスでは、基本的に、アドレス空間で何か他のものにぶつかるまでです（デフォルトの割り当てメカニズムは、すぐに発生しないようにします）。

もちろん、64ビットマシンでは、より多くのアドレス空間で遊ぶことができます。

いずれの場合も、仮想メモリが不足する可能性があります。その場合、SIGBUSまたはSIGSEGVなどが発生します。

Answer 4

受け入れられた答えにコメントしただろうが、どうやら私はもっと多くの担当者が必要です...。

True Stack Overflowは微妙な場合があり、エラーメッセージや警告が常に発生するとは限りません。唯一の症状は、ソケット接続が奇妙なSSLエラーで失敗するという状況でした。他のすべてはうまくいきました。スレッドはmalloc（）、ロックの取得、DBとの通信などが可能です。しかし、新しい接続はSSLレイヤーで失敗します。

GnuTLS内のスタックトレースで、私は本当の原因についてかなり混乱していました。それを理解しようと多くの時間を費やした後、彼らのチームに痕跡をほぼ報告しました。

最終的に、スタックサイズが8Mbに設定されていることがわかり、それを上げるとすぐに問題は解消されました。スタックを8Mbに戻すと、問題が再発しました（ABA）。

したがって、他の警告や初期化されていないメモリエラーなしで奇妙なソケットエラーのように見えるものをトラブルシューティングしている場合は、スタックオーバーフローである可能性があります。