SIGALTSTACK

Section: Linux Programmer's Manual (2)
Updated: 2010-09-26
Index JM Home Page
 

名前

sigaltstack - シグナルスタックのコンテキストを設定・取得する  

書式

#include <signal.h>

int sigaltstack(const stack_t *ss, stack_t *oss);

glibc 向けの機能検査マクロの要件 (feature_test_macros(7) 参照):

sigaltstack():

_BSD_SOURCE || _XOPEN_SOURCE >= 500 || _XOPEN_SOURCE && _XOPEN_SOURCE_EXTENDED
|| /* glibc 2.12 以降: */ _POSIX_C_SOURCE >= 200809L
 

説明

sigaltstack() を使うと、 プロセスは新しい代替シグナルスタックを定義したり、 既存の代替シグナルスタックの状態を取得できる。 シグナルハンドラーが代替シグナルスタックを要求するように設定されていると (sigaction(2) 参照)、ハンドラーの実行中はそのシグナルスタックが使われる。

代替シグナルスタックを使う際の一般的な手順は、以下の通りである:

1.
代替シグナルスタックで使うメモリー領域を確保する。
2.
sigaltstack() を使って、 代替シグナルスタックの存在と場所をシステムに知らせる。
3.
sigaction(2) を使ってシグナルハンドラーを確立する際、 SA_ONSTACK フラグを指定することにより、 そのシグナルハンドラーを代替シグナルスタック上で実行することを システムに知らせる。

ss 引き数は、新しいシグナルスタックを指定するために使う。 また oss 引き数は、現在確立されている シグナルスタックの情報を取得するために使う。 この操作のうち 1 つだけを実行させるには、 使用しない引き数を NULL に指定すればよい。 引き数となる構造体は、以下のような型である:

typedef struct {
    void  *ss_sp;     /* スタックのベースアドレス */
    int    ss_flags;  /* フラグ */
    size_t ss_size;   /* スタックのバイト数 */
} stack_t;

新規の代替シグナルスタックを確立するには、 ss.ss_flags を 0 に設定し、 ss.ss_spss.ss_size に スタックの開始アドレスとスタックサイズを指定する。 定数 SIGSTKSZ は、代替シグナルスタックが通常必要する サイズよりも充分大きく定義されている。 また定数 MINSIGSTKSZ は、 シグナルハンドラーの実行に必要な最小サイズに定義されている。

代替スタックでシグナルハンドラーが起動された場合には、 カーネルにより自動的に、ss.ss_sp で指定されたアドレスは 動作しているハードウェアアーキテクチャーに適したアドレス境界に 調整される。

既存のスタックを無効にするには、 ss.ss_flagsSS_DISABLE に指定する。 この場合、ss の他のフィールドは無視される。

oss が NULL 以外の場合、 oss に代替シグナルスタックの情報が返される。 これは (実質的に) sigaltstack() の呼び出しより先に行われる。 oss.ss_sposs.ss_size フィールドに スタックの開始アドレスとスタックサイズが返される。 oss.ss_flags には以下のどちらかの値が返される:

SS_ONSTACK
プロセスが代替シグナルスタック上で実行されている (プロセスが既にそのシグナルスタック上で実行されている場合は、 それと同じシグナルスタックには変更できない点に注意すること)。
SS_DISABLE
代替シグナルスタックが現在無効になっている。
 

返り値

sigaltstack() は成功した場合 0 を返す。 失敗した場合は -1 を返して、 エラーを示す値に errno を設定する。  

エラー

EFAULT
ss または oss のどちらが、NULL 以外で、 かつプロセスのアドレス空間の外を指している。
EINVAL
ss が NULL 以外で、ss_flags フィールドが SS_DISABLE 以外の 0 でない値になっている。
ENOMEM
新しい代替シグナルスタック (ss.ss_size) に指定したサイズが MINSTKSZ より小さかった。
EPERM
代替シグナルスタックが有効であるときに変更を行おうとした (つまり、プロセスが既に現在の代替シグナルスタック上で実行されていた)。
 

準拠

SUSv2, SVr4, POSIX.1-2001.  

注意

代替シグナルスタックを使用する最もよくある場面は、 SIGSEGV シグナルを扱うときである。 SIGSEGV はプロセスの通常のスタックが利用できる空間が使い果たされた際に 生成されるシグナルである。この場合には、 SIGSEGV 用のシグナルハンドラーをプロセスのスタック上では起動することができない。 そのため、このシグナルを扱おうとする場合には、 代替シグナルスタックを使用しなければならない。

プロセスが標準のシグナルスタックを使い果たすことが予想される場合は、 代替シグナルスタックを確立すると便利である。 例えば、スタックが最上位アドレスから 下位アドレス方向に非常にたくさん積まれてしまうことで、 最下位アドレスから上位アドレス方向に積まれるヒープとぶつかってしまう場合や、 setrlimit(RLIMIT_STACK, &rlim) の呼び出しで確立された 制限に達してしまった場合に、この様な事が起こる。 標準のスタックを使い果たしてしまうと、 カーネルはプロセスに SIGSEGV シグナルを送る。 このような状況では、代替シグナルスタック上でしかシグナルをキャッチできない。

Linux がサポートする多くのハードウェアアーキテクチャーでは、 スタックは下位アドレス方向に積まれる。 sigaltstack() はスタックが積まれる方向を自動的に決定する。

代替シグナルスタック上で実行されている シグナルハンドラーから呼ばれる関数も、代替シグナルハンドラーを使う (プロセスが代替シグナルスタック上で実行されている場合、 他のシグナルで呼び出されるハンドラーもこの代替シグナルハンドラーを使う)。 標準のスタックとは異なり、 システムは代替シグナルスタックを自動的に拡張しない。 代替シグナルスタック用に確保したサイズを越えた場合、 結果は予想できない。

execve(2) の呼び出しが成功すると、 既存の全ての代替シグナルスタックが削除される。 fork(2) 経由で作成された子プロセスは、親プロセスの代替シグナルスタックの 設定のコピーを継承する。

sigaltstack() は以前の sigstack() を置き換えるものである。 過去プログラムとの互換性のため、glibc では sigstack() も提供している。 新しいのアプリケーションは全て sigaltstack() を使って書くべきである。  

歴史

4.2BSD には sigstack() システムコールがあった。 この関数は少し異なった構造体を使っており、 呼び出した側がスタックの積まれる方向を知っていなければならないという 大きな欠点があった。  

以下のコードで sigaltstack() の使用法の一部を示す:
stack_t ss;

ss.ss_sp = malloc(SIGSTKSZ);
if (ss.ss_sp == NULL)
    /* ハンドルエラー */;
ss.ss_size = SIGSTKSZ;
ss.ss_flags = 0;
if (sigaltstack(&ss, NULL) == -1)
    /* ハンドルエラー */;
 

関連項目

execve(2), setrlimit(2), sigaction(2), siglongjmp(3), sigsetjmp(3), signal(7)  

この文書について

この man ページは Linux man-pages プロジェクトのリリース 3.79 の一部である。 プロジェクトの説明とバグ報告に関する情報は http://www.kernel.org/doc/man-pages/ に書かれている。

関連キーワード

スタック, シグナル, 代替, sigaltstack, プロセス, シグナルハンドラー, アドレス, 実行, SIGALTSTACK, flags

Linux マニュアル 一覧

[man1] [man2] [man3] [man4] [man5] [man6] [man7] [man8]
[a] [b] [c] [d] [e] [f] [g] [h] [i] [j] [k] [l] [m] [n] [o] [p] [q] [r] [s] [t] [u] [v] [w] [x] [y] [z]

 

Index

名前
書式
説明
返り値
エラー
準拠
注意
歴史
関連項目
この文書について

This document was created by man2html, using the manual pages.
Time: 12:08:43 GMT, June 11, 2022