Re: Arret d'un programme

Page principale

Répondre à ce message
Auteur: Yves Martin
Date:  
À: guilde
Sujet: Re: Arret d'un programme
En réponse à Edgar Bonet <guilde@???>:

> Le mardi 11 juin, Frédéric Ollivier a écrit :
> > a quoi sert donc tout ces manières pour tuer une tache ?
> >
> >  kill -l
> >  1) SIGHUP       2) SIGINT       3) SIGQUIT      4) SIGILL
> >  [...]

>
> 1) À lui dire qu'on est partis
> 2) Interruption avec Control-C
> 3) Quit au clavier (Control-\)
> 4) Lui faire croire qu'il a une instruction illégale dans son code
> [...]


"lui faire croire", oui, si on envoie le signal par 'kill'
mais ces signaux sont à l'origine des messages transmis par le noyau
et correspondent souvent à des exceptions du processeur.

Par exemple SIGILL est le signal correspondant si le processeur lève
une exception en essayant d'exécuter une instruction inconnue.

  De même, correspondent à des exceptions processeurs:
  SIGFPE : Floatting Point Exception  (FPU inexistant par exemple)
  SIGTRAP : Tentative d'appel privilégié par 'INT'
  SIGBUS : Erreur d'accès au bus
  SIGSEGV : 'Segmentation fault' ou 
            plutôt en langage Intel 'General protection fault'
  SIGCONT : poursuivre (après un arrêt pour débuggage)
  SIGSTOP : point d'arrêt pour débug


Ces signaux sont standards mais leur correspondance avec le processeur
dépend de l'architecture (comme la signification de SEGV sous Intel).
Les autres signaux sont effectivement plus à usage du développeur
(USR1, USR2).

Chaque processus peut décider avec un masque d'écouter ou pas
certains signaux, reste à savoir s'il est capable de l'interpréter et
d'agir en conséquence.

Les signaux sont un concept de communication asynchrone par message
entre le noyau et le processus ou simplement entre processus
(père - fils ou autres) et le fait que l'on puisse envoyer n'importe
quel signal par 'kill' est anecdotique et ne signifie pas que le
signal en question va provoquer la mort du processus.

--
Yves Martin