Lancement d'une exception depuis un gestionnaire de signal

Question

Nous avons une bibliothèque qui traite de nombreux aspects du signalement des erreurs. J'ai été chargé de porter cette bibliothèque sur Linux. Lors de l'exécution de ma petite suite de tests, l'un des tests a échoué. Une version simplifiée du test apparaît ci-dessous.

// Compiler: 4.1.1 20070105 RedHat 4.1.1-52 
// Output: Terminate called after throwing an instance of 'int' abort 

#include <iostream> 
#include <csignal> 
using namespace std; 

void catch_signal(int signalNumber) 
{ 
    signal(SIGINT, SIG_DFL); 
    throw(signalNumber); 
} 

int test_signal() 
{ 
    signal(SIGINT, catch_signal); 

    try 
    { 
     raise(SIGINT); 
    } 
    catch (int &z) 
    { 
     cerr << "Caught exception: " << z << endl; 
    } 
    return 0; 
} 

int main() 
{ 
    try 
    { 
     test_signal(); 
    } 
    catch (int &z) 
    { 
     cerr << "Caught unexpected exception: " << z << endl; 
    } 
    return 0; 
} 

Mon attente est que le Caught exception: le message sera affiché. Qu'est-ce qui se passe réellement, c'est que le programme se termine car aucun gestionnaire de catch semble être présent pour l'int lancé.

Il y a quelques questions sur les SO qui semblent liées. J'ai trouvé un certain nombre de pages Google liées. La «sagesse» semble se résumer à.

1. Ya ne peut pas lancer des exceptions de gestionnaires de signaux, provoque le gestionnaire signal de fonctionne avec sa propre pile, donc il n'y a pas gestionnaires définis sur elle.
2. Ya peut jeter des exceptions à partir des gestionnaires de signaux, il suffit de reconstruire un faux cadre sur la pile, et vous êtes prêt à partir.
3. Ya, on le fait tout le temps. Cela fonctionne pour moi sur la plate-forme X

4. Ya, qui était disponible avec gcc, mais ne semble pas fonctionner plus. Essayez l'option -fnon-call-exceptions, peut-être que cela fonctionnera

   Le code fonctionne comme prévu sur nos compilateurs/environnements AIX/TRU64/MSVC. Il échoue dans notre environnement Linux.

Je cherche des suggestions pour aider à résoudre ce problème afin que le comportement bibliothèque Linux correspondra à mes autres plates-formes, ou une sorte ou solution de contournement qui pourrait atteindre le même type de fonctionnalité.
La suppression du signal de vidage du programme sur le noyau n'est pas une option viable.

Answer 1

Les signaux sont totalement différent des exceptions C++. Vous ne pouvez pas utiliser un bloc try/catch C++ pour gérer un signal. Plus précisément, les signaux sont un concept POSIX, pas un concept de langage C++. Les signaux sont fournis de manière asynchrone à votre application par le noyau, tandis que les exceptions C++ sont des événements synchrones définis par la norme C++.

Vous êtes assez limité dans ce que vous pouvez faire de façon portative dans un gestionnaire de signal POSIX. Une stratégie commune consiste à avoir un indicateur global de type sig_atomic_t qui sera défini sur 1 dans le gestionnaire de signaux, puis éventuellement sur longjmp sur le chemin d'exécution approprié.

Voir here pour l'aide à l'écriture de gestionnaires de signaux appropriés.

Answer 2

Je masquerais tous les signaux dans chaque thread, sauf celui qui attendrait les signaux avec sigwait (). Ce fil peut gérer des signaux sans restriction, par ex. jeter des exceptions ou utiliser d'autres mécanismes de communication.

Answer 3

La suppression d'un gestionnaire de signal n'est probablement pas une bonne idée, car la pile n'est pas nécessairement configurée de la même manière que pour les appels de fonction, donc le déroulement d'un gestionnaire de signal peut ne pas fonctionner comme prévu.

Une note importante doit être prise pour tout registre utilisé par l'ABI C++ qui est sauvegardé et réutilisé par le mécanisme de gestion de signal.

Answer 4

google g ++ Option

-fnon-call-exceptions 

C'est essentiellement ce que vous voulez. Je pense que cela a été développé en raison de la pression de la pomme pour leur OS. Je ne suis pas certain de la façon dont il est pris en charge sur LINUX. Et je ne suis pas certain si l'on peut attraper SIGINT - mais tous les signaux déclenchés par le CPU (aeh exceptions) peuvent être interceptés. Les codeurs qui ont besoin de cette fonctionnalité (et qui ne se soucient pas d'idéologie) devraient créer une pression sur la communauté des développeurs LINUX pour qu'elle soit également supportée sur LINUX un jour - après avoir été supportée par Windows depuis près de deux décennies.

Answer 5

Ce code illustre une technique qui déplace le rejet de l'exception hors du gestionnaire de signal dans le code. Mes remerciements à Charles pour l'idée.

#include <iostream> 
#include <csignal> 
#include <csetjmp> 

using namespace std; 

jmp_buf gBuffer;  // A buffer to hold info on where to jump to 

void catch_signal(int signalNumber) 
{ 
    //signal(SIGINT, SIG_DFL);   // Switch to default handling 
    signal(SIGINT, catch_signal);  // Reactivate this handler. 

    longjmp    // Jump back into the normal flow of the program 
    (
     gBuffer,  // using this context to say where to jump to 
     signalNumber // and passing back the value of the signal. 
    ); 
} 


int test_signal() 
{ 
    signal(SIGINT, catch_signal); 

    try 
    { 
     int sig; 
     if ((sig = setjmp(gBuffer)) == 0) 
     { 
      cout << "before raise\n"; 
      raise(SIGINT); 
      cout << "after raise\n"; 

     } 
     else 
     { 
      // This path implies that a signal was thrown, and 
      // that the setjmp function returned the signal 
      // which puts use at this point. 

      // Now that we are out of the signal handler it is 
      // normally safe to throw what ever sort of exception we want. 
      throw(sig); 
     } 
    } 
    catch (int &z) 
    { 
     cerr << "Caught exception: " << z << endl; 
    } 

    return 0; 
} 

int main() 
{ 
    try 
    { 
     test_signal(); 
    } 
    catch (int &z) 
    { 
     cerr << "Caught unexpected exception: " << z << endl; 
    } 
    return 0; 
}