Est-il possible de ne terminer qu'un seul thread lors de la réception d'un SIGSEGV ?

Question

J'ai une application qui démarre plusieurs threads. J'utilise un gestionnaire de signaux pour capter les signaux.

Je ne veux pas que mon application s'arrête en cours de route. SIGSEGV Je veux terminer seulement le thread qui a reçu le signal, et continuer le flux de l'application complète dans les autres threads. Est-ce possible ?

Answer 1

Si un SIGSEGV se produit, cela indique que votre programme a déjà invoqué un comportement indéfini, c'est-à-dire que l'état de l'ensemble du programme est indéfini/indéterminé/invalide. En pratique, il est possible que vous puissiez récupérer et continuer à fonctionner, mais il n'y a aucune garantie et cela peut être dangereux.

Comme l'a mentionné Asveikau, vous pourriez longjmp hors du gestionnaire de signal et essayer de nettoyer, mais cela pourrait créer un désordre encore pire si le crash se produisait au milieu de malloc , free , printf ou toute fonction modifiant l'état des données globales ou des données qui sont partagées avec d'autres threads ou qui seront accessibles dans le code de nettoyage à l'adresse longjmp destination. L'état peut être corrompu/inconsistant, et/ou des verrous peuvent être retenus et laissés en permanence non libérables.

Si vous pouvez vous assurer que cela ne se produira pas - par exemple si le thread fautif n'appelle jamais de fonctions asynchrones non sûres - alors il peut être sûr de longjmp hors du gestionnaire de signal, puis appeler pthread_exit .

Une autre solution consisterait à geler définitivement le thread dans le gestionnaire de signaux, en ajoutant tous les signaux à l'élément sa_mask pour SIGSEGV puis en écrivant for (;;) pause(); dans le gestionnaire de signal. Cette méthode est "sûre" à 100 %, mais peut laisser le processus dans un état de blocage si des verrous étaient détenus par le thread qui s'est écrasé. C'est peut-être "moins grave" que d'exposer un état corrompu à d'autres threads et de continuer à détruire vos données...