判定を行えば、スタックオーバーフローを補足できる。スタックオーバーフローが発生した時に何らかの処理をした後に元のコンテキストに戻りたい場合には、さらに工夫が必要になる。シグナル発生後の処理の継続方法としては、以下の二通りの方法が考えられる。「スタックオーバーフローが発生しましたよ」という警告フラグを立てておいてシグナルハンドラを脱出。元のコンテキストに戻って処理を再開。使ってそこにジャンプすることで再開する。実現方法について説明する。その前にスタックオーバーフローが発生する機構を再考してみる。スタックオーバーフローの不正アクセス例外はスタック領域の中で発生するように実装されている。設けていて、このページの属性を読み込み・書き込み・実行に設定する。シグナルが発生し、「もうこれ以上はスタックは伸ばせません」ということが通知される。実現方法のために、ユーザーがガード領域を自由に設定する方法を考える。スタックの最終ページをガード領域として設定しているはずである。このシステム定義ガード領域の大きさを何らかの方法によって予め調べておく。用いて動的に取得できる。仮想記憶ページの整数倍となるように設定する。実メモリが貼り付けられていない。用いて強制的に実メモリをり付けてしまう。ユーザー定義ガード領域までスタックが伸びる。ユーザー定義ガード領域内でアクセスバイオレーションが発生したことを確認する。必要な属性に変更する。ここからユーザー独自のスタックオーバーフロー処理を開始する。アクセスバイオレーションが発生した位置から処理が再開する。実行を再開することが可能である。以上のような流れで、ユーザー定義ガード領域を使ったシグナルハンドリングを行えばよい。この方法ではユーザー定義ガード領域は通常のスタック領域に戻ったままなので、どこかのポイントでユーザー定義ガード領域は再設定する必要がある。ここではオリジナルのスタックの下半分をガード領域とする。スタックの中に実メモリをコミットする。スタック領域の中に代替シグナルハンドラも入れてしまえば解決する。スタックの構成を以下のように変更してしまえばよい。使って実メモリを無理矢理貼り付ける。用意した通常のガード領域が使えなくなるので、代替シグナルスタックの上に新しいガード領域を作って自分で管理する必要がある。以上を実現したサンプルプログラムは以下のようになる。案のように、スタックオーバーフローが発生した時に予め登録しておいた場所にジャンプし、そこから再開させる方法もある。