Forum Linux.débutant probleme avec sigaction

Posté par  . Licence CC By‑SA.
Étiquettes : aucune
1
21
fév.
2019

Bonjour à tous,

voila lors d'un segFault je veux récupérer le signal. J'ai donc utilisé sigaction qui conseil de mettre à la fin du handler l'appel systeme raise ou kill. Je m'attendais donc que mon processus tourne en boucle car a chaque signal sigSEGV recu la fonction fToCallIfSegFault est sensé etre appelé, et pourtant non, pourquoi ?

voici mon code :

#define SIGSEGV 11

void fToCallIfSegFault(int sig)
{
    fprintf(stdout, "il y a eu un segfault dans ton code mon coco, le sig = %i\n", sig);
    kill(getpid(), sig);
}

int main(int argc, char const *argv[])
{
    struct sigaction act;
    act.sa_handler = fToCallIfSegFault;
    sigaction(SIGSEGV, &act, NULL);

    //on genere un segfault
    char* str = NULL;
    str[0] = 'c'; //erreur de segmentation

    return 0;
}

merci d'avance pour votre aide

  • # Étrange, mais un (équivalent de) raise() depuis un gestionnaire de signaux…

    Posté par  (site web personnel) . Évalué à 2.

    De mon côté, une fois que j'ai ajouté les #include qui manquent, soit :

    #include <signal.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

#define SIGSEGV 11

void fToCallIfSegFault(int sig)
{
    fprintf(stdout, "il y a eu un segfault dans ton code mon coco, le sig = %i\n", sig);
    kill(getpid(), sig);
}

int main(int argc, char const *argv[])
{
    struct sigaction act;
    act.sa_handler = fToCallIfSegFault;
    sigaction(SIGSEGV, &act, NULL);

    //on genere un segfault
    char* str = NULL;
    str[0] = 'c'; //erreur de segmentation

    return 0;
}

    J'ai bien ceci en boucle :

    il y a eu un segfault dans ton code mon coco, le sig = 11
il y a eu un segfault dans ton code mon coco, le sig = 11
il y a eu un segfault dans ton code mon coco, le sig = 11

    … ou bien un arrêt instantané, ou bien un arrêt après plus ou moins longtemps.

    Dans mes vieux souvenirs (mais je n'ai pas de source pour cela), il me semble qu'on disait qu'un gestionnaire de signal, sur SIGSEGV du moins, était censé faire une chose et une seule : appeler backtrace, finir de loguer et quitter.

    Quoi qu'il en soit, je t'invite à lire (en anglais) cette section de la page wikipedia sur les signaux, notamment la première phrase :

    Signal handling is vulnerable to race conditions.

    Debian Consultant @ DEBAMAX

  • # undefined behaviour

    Posté par  (site web personnel) . Évalué à 5.

    According to POSIX, the behavior of a process is undefined after it ignores a SIGFPE, SIGILL, or SIGSEGV signal that was not generated by kill(2) or raise(3).

    Par ailleurs, fprintf(3) n'est pas dans la liste des fonctions qu'il soit sûr d'appeler depuis une fonction de gestion de signal.

    signal(2)
    signal-safety(7)

    Donc je ne connais pas la raison exacte qui résulte dans le comportement que tu décris mais ce comportement est légitime puisque ton programme invoque un comportement indéfini.

    https://en.wikipedia.org/wiki/Undefined_behavior

    Maintenant, si tu peux explique le problème que tu essaies de résoudre, peut-être qu'on peut suggérer des solutions qui marchent.

    pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

    • [^] # Re: undefined behaviour

      Posté par  . Évalué à 2. Dernière modification le 22 février 2019 à 10:46.

      je ne comprend pas pourquoi tu dis que le comportement est indéfini.

      quand mon processus recoit le signal SIGSEGV il est sensé appelé la fonction tToCallIfsegFault. Donc techniquement la fonction tToCallIfsegFault devrait tourner en boucle car cette fonction envoie un signal SIGSEGV a son propre PID. Or des fois j'ai une boucle et des fois un core dump. J'aimerai avoir tout le temps le meme résultat et non pas un comportement indéfini

      pour les races conditions, ca veut dire que le probleme est du à la partie électronique du systeme (Timer…) et donc on ne peut rien faire ?

      • [^] # Re: undefined behaviour

        Posté par  (site web personnel) . Évalué à 2.

        Ta fonction de traitement de signal utilise des fonctions qui ne sont pas autorisées dans un gestionnaire de signal. Si tu utilises ce genre de fonctions, tu es hors jeu. Tout peut arriver. Undefined Behaviour (UB), c'est potentiellement aller écrire des zéros dans tous tes fichiers, puis tout supprimer, et faire chanter la Marseillaise à ton PC speaker. Cela peut également vouloir dire boucler sans arrêt, ou s'arrêter dès le premier passage dans cette fonction (les différents comportements que je décrivais).

        Si tu veux des résultats prédictibles et définis, ne t'expose pas à des comportements indéfinis. Respecte les règles.

        Quant aux race conditions, pas vraiment de rapport avec l'électronique à proprement parler. Un système informatique est constitué de plein d'événements concurrents. En fonction du timing, on peut se retrouver avoir des choses qui marchent©®™ ou pas-marchent©®™, par exemple parce que les signaux ont été reçus/traités plus ou moins rapidement, ou dans un ordre donné, ou en interrompant telle autre routine, etc.

        Debian Consultant @ DEBAMAX

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.