Provided by: manpages-fr-dev_4.21.0-2_all bug

NOM

       sigaltstack - Consulter ou définir la pile de signal

BIBLIOTHÈQUE

       Bibliothèque C standard (libc, -lc)

SYNOPSIS

       #include <signal.h>

       int sigaltstack(const stack_t *_Nullable restrict ss,
                       stack_t *_Nullable restrict old_ss);

   Exigences    de    macros    de   test   de   fonctionnalités   pour   la   glibc   (consulter
   feature_test_macros(7)) :

       sigaltstack() :
           _XOPEN_SOURCE >= 500
               || /* Depuis la glibc 2.12 : */ _POSIX_C_SOURCE >= 200809L
               || /* glibc <= 2.19 : */ _BSD_SOURCE

DESCRIPTION

       sigaltstack() permet à un  thread  de  définir  une  nouvelle  pile  spécifique  pour  les
       gestionnaires  de  signaux  et/ou de récupérer l'état d'une pile spécifique de signal déjà
       existante. Une pile spécifique de signal est utilisée durant l'exécution d'un gestionnaire
       de signal si la mise en place de ce gestionnaire (consultez sigaction(2)) le spécifiait.

       La  séquence  d'actions  nominale  pour  utiliser  une  pile  spécifique  de signal est la
       suivante :

       1. Allouer une zone mémoire qui sera utilisée comme pile spécifique de signal.

       2. Utiliser sigaltstack() afin d'informer le système de l'existence et de la  position  de
          la pile spécifique de signal.

       3. Lors  de la mise en place du gestionnaire de signal en utilisant sigaction(2), informer
          le système que ce gestionnaire de signal doit être exécuté sur la  pile  spécifique  de
          signal en positionnant le drapeau SA_ONSTACK.

       L'argument  ss  est utilisé afin de définir une nouvelle pile spécifique de signal, tandis
       que l'argument old_ss est utilisé afin de récupérer des informations sur la pile de signal
       actuellement  en place. Si une seule de ces actions vous intéresse, alors l'autre argument
       peut être positionné à NULL.

       Le type stack_t utilisé pour typer les paramètres  de  cette  fonction  est  défini  comme
       suit :

           typedef struct {
               void  *ss_sp;     /* Adresse de base de la pile*/
               int    ss_flags;  /* Drapeaux */
               size_t ss_size;   /* Nombre d'octets dans la pile */
           } stack_t;

       Pour mettre en place une nouvelle pile de signal spécifique, les champs de cette structure
       sont définis comme suit :

       ss.ss_flags
              Ce champ contient soit 0, soit le drapeau suivant :

              SS_AUTODISARM (depuis Linux 4.7)
                     Effacer les paramètres de la pile de signal spécifique lors de l'entrée dans
                     le  gestionnaire  de  signal.  Au  renvoi  du  gestionnaire  de  signal, les
                     paramètres de la pile de signal spécifique seront restaurés.

                     Ce drapeau a été ajouté afin de sécuriser la désactivation d'un gestionnaire
                     de  signal  avec swapcontext(3). Sans ce drapeau, un signal géré après cette
                     désactivation corrompra l'état du gestionnaire de signal désactivé. Sur  les
                     noyaux  où  ce  drapeau  n'est pas pris en charge, sigaltstack() échoue avec
                     l'erreur EINVAL quand ce drapeau est fourni.

       ss.ss_sp
              Ce champ indique l'adresse de début de la pile. Lorsqu'un  gestionnaire  de  signal
              est appelé sur la pile spécifique, le noyau aligne automatiquement l'adresse donnée
              dans ss.ss_sp sur une valeur correcte pour l'architecture matérielle utilisée.

       ss.ss_size
              Ce champ spécifie l'adresse de la pile. La constante SIGSTKSZ est définie de  façon
              à  être  suffisamment  grande  pour  couvrir les besoins typiques en espace mémoire
              d'une pile spécifique de signal, et la  constante  MINSIGSTKSZ  définit  la  taille
              minimale nécessaire à l'exécution d'un gestionnaire de signal.

       Afin  de désactiver une pile existante, positionnez ss.ss_flags à SS_DISABLE. Dans ce cas,
       le noyau ignore tous les autres drapeaux de ss.ss_flags et les autres champs de ss.

       Si old_ss ne vaut pas NULL, alors il est utilisé afin de renvoyer des informations sur  la
       pile  spécifique  de  signal  qui était utilisée avant l'appel à sigaltstack(). Les champs
       old_ss.ss_sp et old_ss.ss_size renvoient l'adresse de départ et la taille de  cette  pile.
       Le champ old_ss.ss_flags peut renvoyer l'une des valeurs suivantes :

       SS_ONSTACK
              Le thread s'exécute actuellement sur la pile spécifique de signal. (Remarquez qu'il
              n'est pas possible de changer la pile spécifique de signal  si  le  thread  est  en
              train de s'exécuter sur cette dernière.)

       SS_DISABLE
              La pile spécifique de signal est actuellement désactivée.

              Sinon,  cette  valeur  est  renvoyée si le processus s'exécute actuellement sur une
              pile de signal spécifique mise en place en utilisant le drapeau SS_AUTODISARM. Dans
              ce   cas,   il   est  plus  sûr  de  désactiver  le  gestionnaire  de  signal  avec
              swapcontext(3). Il est également possible de définir une autre pile  spécifique  en
              utilisant un autre appel sigaltstack().

       SS_AUTODISARM
              La  pile  spécifique  de  signal  a  été  marquée pour être désactivée comme décrit
              ci-dessus.

       En positionnant ss sur NULL et old_ss sur une valeur autre que NULL, on peut  obtenir  les
       paramètres de la pile de signal spécifique sans les modifier.

VALEUR RENVOYÉE

       sigaltstack() renvoie 0 en cas de succès, ou -1 en cas d'échec en positionnant alors errno
       pour préciser l'erreur.

ERREURS

       EFAULT Un des paramètres ss ou old_ss ne vaut pas NULL et pointe  vers  une  zone  mémoire
              n'appartenant pas à l'espace d'adressage du processus.

       EINVAL ss ne vaut pas NULL et le champ ss_flags contient une valeur non valable.

       ENOMEM La  taille  de  la  nouvelle  pile  spécifique  de signal indiquée (ss.ss_size) est
              inférieure à MINSIGSTKSZ.

       EPERM  On a essayé de modifier la pile spécifique  de  signal  alors  que  celle-ci  était
              active  (c'est-à-dire,  le  thread  était  déjà  en train de s'exécuter sur la pile
              spécifique de signal courante).

ATTRIBUTS

       Pour une explication des termes utilisés dans cette section, consulter attributes(7).

       ┌────────────────────────────────────────────────────────┬──────────────────────┬─────────┐
       │InterfaceAttributValeur  │
       ├────────────────────────────────────────────────────────┼──────────────────────┼─────────┤
       │sigaltstack()                                           │ Sécurité des threads │ MT-Safe │
       └────────────────────────────────────────────────────────┴──────────────────────┴─────────┘

STANDARDS

       POSIX.1-2001, POSIX.1-2008, SUSv2, SVr4.

       Le drapeau SS_AUTODISARM est une extension de Linux.

NOTES

       Le cas le plus courant d'utilisation d'une pile spécifique est pour la gestion  du  signal
       SIGSEGV  qui  est  généré si la place disponible pour la pile normale est épuisée. Dans ce
       cas, un gestionnaire pour SIGSEGV ne peut pas être exécuté sur la pile standard ; si  l'on
       souhaite l'intercepter, on doit utiliser une pile spécifique.

       La  mise  en  place d'une pile spécifique de signal est utile si un thread soupçonne qu'il
       est susceptible d'épuiser sa pile standard. Cela peut se produire, par exemple, lorsque la
       pile  grossit  au  point de rencontrer la limite supérieure du tas, ou si elle atteint une
       limite établie par un appel à setrlimit(RLIMIT_STACK, &rlim).  Si  la  pile  standard  est
       épuisée,  le noyau envoie au processus un signal SIGSEGV. Dans ces circonstances, la seule
       façon d'intercepter ce signal est d'utiliser une pile spécifique de signal.

       Sur la plupart des architectures supportées par  Linux,  les  piles  s'étendent  vers  les
       adresses  décroissantes. sigaltstack() prend automatiquement en charge le sens d'expansion
       de la pile.

       Les fonctions  appelées  depuis  un  gestionnaire  de  signal  s'exécutant  sur  une  pile
       spécifique de signal utilisent également cette pile. (Cela s'applique également à tous les
       gestionnaires invoqués pour d'autres signaux alors que le thread  s'exécute  sur  la  pile
       spécifique  de  signal.)  Contrairement  à  la  pile  standard,  le  système n'accroît pas
       automatiquement la pile spécifique de signal. Dépasser la  taille  allouée  pour  la  pile
       spécifique de signal conduit à des résultats imprévisibles.

       Un  appel  execve(2)  réussi supprime toutes les piles de signal spécifiques. Un processus
       enfant créé à l'aide de fork(2) hérite d'une copie des paramètres de  la  pile  de  signal
       spécifique  de  son  parent.  Cela vaut aussi pour un processus enfant créé avec clone(2),
       sauf si les drapeaux de clone incluent CLONE_VM et n'incluent pas CLONE_VFORK, auquel  cas
       toutes  les  piles  de  signal  spécifique  mises  en  place dans le processus parent sont
       désactivées dans le processus enfant.

       sigaltstack() succède à l'ancien appel sigstack(). Pour des raisons de  compatibilité,  la
       glibc  implémente  sigstack(). Toutes les nouvelles applications devraient être écrites en
       utilisant sigaltstack().

   Historique
       BSD 4.2 possédait un appel système  sigstack().  Il  utilisait  une  structure  légèrement
       différente, et avait comme désavantage principal la nécessité pour l'appelant de connaître
       le sens d'expansion de la pile.

BOGUES

       Dans  Linux 2.2,  le  seul  drapeau  qui  pouvait  être  indiqué  dans  ss.sa_flags  était
       SS_DISABLE.  À  partir  de  la publication du noyau Linux 2.4, un changement a été apporté
       pour permettre à sigaltstack() d'autoriser ss.ss_flags==SS_ONSTACK à avoir  le  même  sens
       que  ss.ss_flags==0  (à  savoir  que  l'inclusion  de  SS_ONSTACK dans ss.ss_flags est une
       non-op). Sur d'autres implémentations et selon POSIX.1, SS_ONSTACK n'apparaît que comme un
       drapeau  signalé  dans  old_ss.ss_flags.  Sur  Linux,  il n'y a même pas besoin d'indiquer
       SS_ONSTACK dans ss.ss_flags, et en effet, vous devriez éviter de le faire pour des raisons
       de  portabilité :  plusieurs  autres systèmes donnent une erreur si SS_ONSTACK est indiqué
       dans ss.ss_flags.

EXEMPLES

       Le bout de code suivant montre l'utilisation de sigaltstack() (et  de  sigaction(2))  pour
       installer  une  pile  de  signal  spécifique  utilisée  par le gestionnaire pour le signal
       SIGSEGV :

           stack_t ss;

           ss.ss_sp = malloc(SIGSTKSZ);
           if (ss.ss_sp == NULL) {
               perror("malloc");
               exit(EXIT_FAILURE);
           }

           ss.ss_size = SIGSTKSZ;
           ss.ss_flags = 0;
           if (sigaltstack(&ss, NULL) == -1) {
               perror("sigaltstack");
               exit(EXIT_FAILURE);
           }

           sa.sa_flags = SA_ONSTACK;
           sa.sa_handler = handler();      /* Address of a signal handler */
           sigemptyset(&sa.sa_mask);
           if (sigaction(SIGSEGV, &sa, NULL) == -1) {
               perror("sigaction");
               exit(EXIT_FAILURE);
           }

VOIR AUSSI

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

TRADUCTION

       La traduction française de cette  page  de  manuel  a  été  créée  par  Christophe  Blaess
       <https://www.blaess.fr/christophe/>,  Stéphan  Rafin  <stephan.rafin@laposte.net>, Thierry
       Vignaud <tvignaud@mandriva.com>, François Micaux, Alain  Portal  <aportal@univ-montp2.fr>,
       Jean-Philippe    Guérard   <fevrier@tigreraye.org>,   Jean-Luc   Coulon   (f5ibh)   <jean-
       luc.coulon@wanadoo.fr>,   Julien    Cristau    <jcristau@debian.org>,    Thomas    Huriaux
       <thomas.huriaux@gmail.com>, Nicolas François <nicolas.francois@centraliens.net>, Florentin
       Duneau <fduneau@gmail.com>, Simon Paillard <simon.paillard@resel.enst-bretagne.fr>,  Denis
       Barbier   <barbier@debian.org>,   David   Prévot  <david@tilapin.org>,  Cédric  Boutillier
       <cedric.boutillier@gmail.com>, Frédéric Hantrais  <fhantrais@gmail.com>  et  Jean-Philippe
       MENGUAL <jpmengual@debian.org>

       Cette  traduction  est  une  documentation libre ; veuillez vous reporter à la GNU General
       Public  License  version 3  ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩   concernant   les
       conditions de copie et de distribution. Il n'y a aucune RESPONSABILITÉ LÉGALE.

       Si vous découvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un
       message à ⟨debian-l10n-french@lists.debian.org⟩.