スタックオーバーフロー

マルチタスク環境では、複数のタスクが同時並行的に動作したよね。これはつまり、それぞれのタスクは別々の関数を独立して実行しているということなんだ。

このことを実現するために、スタックメモリはタスクごとに別々に割り当てられるんだ。ここで、ひとつ関数を考えてみよう。特定のファイルから配列のバッファにデータを読み出すというソースコードだよ。

さらに、変数sizeやopen(), read()等の関数で宣言されているAuto変数は、その後ろに積まれていくから、どんどんはみ出していくんだ。

ここで、buf[]にデータを読み込んだり、sizeに値を代入したりすると、「別の目的で使用されているメモリ」を壊してしまうことになってしまう。その結果、システムが正しく動作しなくなったり、最悪はプログラム例外を起こしてシステムがハングアップすることが予想される。この現象を「スタックオーバーフロー」というんだ。

スタックオーバーフローを起こさないためには

スタックオーバーフローが起こるかどうかは「タスクのスタックサイズ」に依存する。つまり、同じ関数でも「大きなスタックメモリを持つタスクB」で実行すれば表面化しないんだ。これも問題をやっかいにしている一因だね。

WindowsやLinuxなどの汎用OSでは、プロセス（スレッド）に割り当てられる標準のスタックサイズが大きい（1MBなど）から、実はスタックオーバーフローの問題はほとんど起こらないんだ。だけど、限られたメモリ資源で動作する組込みシステムでは、大きなスタックメモリを潤沢に割り当てることはできない。場合によっては、タスクの関数コールシーケンスを詳細に解析して、スタックメモリをギリギリまでチューニングしなければならないケースもあるくらいだよ。

だから、この問題は、WindowsやLinuxのシステムで動作していた プログラムを組込みシステムに移植したときに、表面化しやすいと言えるね。

プログラミング上の注意

スタックオーバーフローを起こさないソースコードを書くときの注意点をあげてみよう。

1. 大きなデータをAuto変数として宣言しない
2. 再帰呼び出しを使わない

（1）大きなデータをAuto変数として宣言しない

前半で例にあげたように「大きな配列をAuto変数で宣言する」のは、直接的にスタックオーバーフローを引き起こす原因になるから、避けるべきなんだ。だけど、配列の要素数が少なければよいのかというとそうでもない。

例えば、long型配列の場合はchar型配列の4倍のメモリが必要になる。配列がどれくらいのメモリを占有するかを意識する必要があるということだね。このような「大きな配列」については、ソースコードを見れば一目瞭然だから、コードレビューを実施することで、事前に潰すことができるんだ。じゃあ、こんな場合はどうだろうか。

MY_DATAという構造体にパラメータを設定して送信するというイメージだよ。ここで、MY_PACKET構造体が以下の形なら、特に問題はないだろうね。

だけど、例えば下のようなUnicode文字列を含む構造体だったとしたらどうだろう？一般的なUnicodeは1文字が2バイトで表現されるから、unsigned shortの配列としてもっているよね。

• malloc()等を使ってヒープメモリから確保する
• グローバル変数として宣言する
• Auto変数宣言にstatic修飾子をつける

「どこに確保されるのか？」については、また別の回で話すつもりだから、待っててね。コード例1をグローバル変数を使って修正したものは下のようになる。Auto変数は、それを指すポインタだけになるんだ。 ポインタ変数は32-bit CPUでは4バイトだから、スタックメモリを圧迫しない。

コード例2では実体であるg_pktが無くなることはないけど、実体を動的に確保した場合には、「ポインタが指している先のメモリがちゃんと存在するか？」などのチェックをする必要が出てくるんだ。

（2）再帰呼び出しを使わない

スタックトレース

スタックメモリの情報は、デバッグ時にとても役に立つんだよ。スタックの中を解析すれば「関数コールのシーケンス」がわかるからなんだ。あるタスクが不具合で止まってしまったときに、

• どの関数のどのあたりを実行していたのか？
• どのようなパスを通ってその関数がコールされたのか？
• 引数の値は？

などが分かったら問題個所を特定しやすいよね。

組込み開発で実際のターゲットボード上のデバッグを行う「デバッガ」と呼ばれる機器には、プログラムの実行を止めたときに、タスクのスタックメモリの内容を関数名で表示させる機能を持ったものがあるんだ。このような機能は「スタックトレース」と呼ばれていて、特に不具合の解析時には大変有効なツールだよ。