2

I am trying to set up an exception handler using sigaction. It works well for the first exception. But the sigaction handler is not called after the 1st exception and the program ends abruptly when the second signal happens.

#include <iostream>
#include <signal.h>
#include <exception>
#include <string.h>

typedef void (*SigactionHandlerPointer)(int iSignal, siginfo_t * psSiginfo, void * psContext);

using namespace std;

void SigactionHookHandler( int iSignal, siginfo_t * psSiginfo, void * psContext )
{
   cout << "Signal Handler Exception Caught: std::exception -- signal : " << iSignal << " from SigactionHookHandler()" << endl;

   throw std::exception();
}

class A
{
public:
   A() {}
   virtual ~A() {}

   virtual void fnct1();
   virtual void fnct2() { fnct3(); }
   virtual void fnct3() { fnct4(); }
   virtual void fnct4();
};

void
A::fnct1()
{
   try {
      fnct2();
   }
   catch( std::exception &ex ) {
      cerr << "Signal Handler Exception Caught" << endl;
   }
   catch (...)
   {
      cerr << "Unknow Exception Caught: " << endl;
   }
}

void
A::fnct4()
{
   *(int *) 0 = 0;  // Access violation
}

int main()
{
   struct sigaction oNewSigAction;
   struct sigaction oOldSigAction;

   memset(&oNewSigAction, 0, sizeof oNewSigAction);

   oNewSigAction.sa_sigaction = SigactionHookHandler;
   oNewSigAction.sa_flags     = SA_SIGINFO;

   int iResult = sigaction( SIGSEGV, &oNewSigAction, &oOldSigAction );

   cout << "sigaction installed handler with status " << iResult << endl;

   A * pA = new A();

   cout << "Next message expected is : <<Signal Handler Exception Caught: std::exception>> to pass this test" << endl;
   pA->fnct1();

   // Second exception will never be call the sigaction handler.
   cout << "Next message expected is : <<Signal Handler Exception Caught: std::exception>> to pass this test" << endl;
   pA->fnct1();

   return 0;
}
Rob Kennedy
  • 161,384
  • 21
  • 275
  • 467
Guy B
  • 217
  • 4
  • 15

2 Answers2

8

Signals and exceptions are not related to each other. What you're using (throwing exceptions from async signal handlers) is only portable between the few compilers that support it, such as GCC and Intel C/C++ with -fnon-call-exceptions.

That said, what you forgot to do is unblock the signal: when a signal handler is executing, the delivery of the same signal is blocked, and it does not become unblocked when the signal handler is exited through an exception. Change the signal handler as follows:

void SigactionHookHandler( int iSignal, siginfo_t * psSiginfo, void * psContext
{
   cout << "Signal Handler Exception Caught: std::exception -- signal : " << iSignal << " from SigactionHookHandler()" << endl;

   sigset_t x;
   sigemptyset (&x);
   sigaddset(&x, SIGSEGV);
   sigprocmask(SIG_UNBLOCK, &x, NULL);

   throw std::exception();
}
Cubbi
  • 46,567
  • 13
  • 103
  • 169
  • I work with both GNU GCC an Intel compiler. I used the -fnon-call-exceptions option. The suggested patch works. Note however that I changed the sigprocmask(SIG_UNBLOCK, &x, NULL); to pthread_sigmask(SIG_UNBLOCK, &x, NULL); since I have a multithreaded application. However I am still baffled. The gcc-lib manual states : "...In any case, when the handler returns, the system restores the mask that was in place before the handler was entered...." And if I comment the throw std::exception() in the original code then after the signal handler is called I do return to the original exception – Guy B May 03 '11 at 13:15
  • (.. continued from previous comment...) and the signal handler is called again and again... Thus I didn't expect to have to unblock the signal myself. What did I miss? – Guy B May 03 '11 at 13:19
  • @Guy B: So it appears the manual is wrong when it says "in any case", although one could argue that throwing an exception is not the same as "returning". FWIW, this reproduces for me on gcc 3.4.6, gcc 4.4.1, gcc 4.5.2, and gcc 4.6.0. – Cubbi May 03 '11 at 14:26
  • After pondering the issue I believe I found the answer. By doing a throw inside the handler the C run time library must unwind the caller stack to the catch entering point. Thus the restore of the original mask from returning of the signal handler is lost. So you have to do the job of the caller of the signal handler would have done. There is no problem if you don't do a throw. The original mask is restored. I am wondering if this can be considered a bug of the run time library? Anyway thanks for the solution – Guy B May 03 '11 at 14:51
  • @Guy B: Perhaps it can be considered a bug -- let's see what the gcc folks think: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48854 – Cubbi May 03 '11 at 14:55
2

Standard C++ says nothing about signals, or about how they interact with exceptions. What you are trying to do will be completely specific to the OS platform you are using and possibly the specific compiler you compile your code with.