Home / Questions / 28884
Accepted
cheroky
Asked: 2020-10-20 18:20:52 +0800 CST 2020-10-20 18:20:52 +0800 CST

Is it possible to catch a segfault with try/catch?

  • 772

To check if it is possible I did the following:

try
{
    int *x = 0;
    *x = 1234;
}
catch(...)
{
    cout << "OK";
}

But when I run it, I still get a segfault. I've read on some sites that try/catch can't catch a segfault, but I don't know if that's true, could someone please confirm that for me.

c++

2 Answers

  1. Best Answer

    In any language, exceptions are not generated spontaneously, but it is the code itself that is responsible for throwing them.

    Thus, for example, newit throws an exception when the requested reservation cannot be made. Simplifying a lot, this would be a possible example of implementation of new:

    int* new(unsigned int numElementos)
{
  int* ptr = (int*)malloc(sizeof(int)*numElementos);
  if(ptr == nullptr)
    throw std::bad_alloc();

  return ptr;
}

    In the case of the example that you have given, access to an uninitialized pointer does not call any element of the standard library that can generate exceptions. This is where the operating system comes into play. Modern Operating Systems are able to monitor memory access and throw errors when trying to access memory for which there is no access. Since the responsibility for causing a failure lies with the Operating System, the solution to apply to control these accesses depends on the Operating System on which the application is going to run.

    • As a general rule, on Windows these types of errors can be caught using __tryand __except. More information here
    • On Linux the error can be caught by listening for the SIGSEV signal. A possible solution in this case, with the idea of ​​managing exceptions, is to catch the signal and throw the corresponding exception:

    Windows example:

    #include <iostream>
#include <windows.h> 
#include <excpt.h>

int filter(unsigned int code, struct _EXCEPTION_POINTERS *ep)
{
   if (code == EXCEPTION_ACCESS_VIOLATION)
      return EXCEPTION_EXECUTE_HANDLER;

   return EXCEPTION_CONTINUE_SEARCH;
}

int main()
{
   int* ptr = 0;

   __try
   {
     *ptr = 10;
   }
   __except(filter(GetExceptionCode(), GetExceptionInformation()))
   {
     std::cout << "Access Violation\n";
   }
}

    SIGSEV example:

    class SigSevException : public std::exception
{
public:
  SigSevException () noexcept
   : std::exception()
     m_what("Segmentation Fault")
  {}

  SigSevException (const SigSevException &) noexcept = default;

  SigSevException& operator= (const SigSevException &) noexcept = default;

  virtual ~SigSevException() = default;

  const char* what() const noexcept override
  {
    return m_what.c_str();
  }

private:

  std::string m_what;
};

void SignalSIGSEV(int signal)
{
  std::cerr << "señal SIGSEV lanzada";
  throw SigSevException();
}

int main()
{
  signal(SIGSEGV , SignalHandler);

  try
  {
    int* ptr;
    *ptr = 85;
  }

  catch(const std::exception& exc)
  {
    std::cout << exc.what();
  }
}

    All the best.

    • 2

  2. No, a segmentation fault is a signal, not an exception. Exceptions are manually thrown by the program (either you or a library), while signals are generated by the operating system ( SIGSEGV, SIGABRT, SIGKILL, etc ).

    Exceptions are caught with try/ blocks catch, and signals with signal handlers.

    Signals cannot be treated as exceptions because exceptions are thrown on a specific line of the program (where you put throw), while signals can appear at any time (since they are like interrupts, for example the user pressing Ctrl-C also generates a signal, SIGINT).

    Exception handling involves adding, by the compiler, some control code in the final executable for stack unwinding (the destruction of local objects as the exception traverses functions) and try/ logic catch(the end of stack unwinding ).

    For signals, that control code cannot be placed around any particular line of code because signals are received "outside", like a stone being thrown at you. They can happen at any time.

    Even if you think a SIGSEGVhappens, or is thrown , on the line accessing the wrong memory location, it actually doesn't, or doesn't have to (as far as I know). The signal does not have to be received at the moment that said memory is accessed (that is, it is not launched on the line that detects the situation), but it can come with a certain delay, or never arrive if the accessed memory is also it belongs to your program (to another object, although in this case you will possibly observe UB- undefined behavior - in execution).

    • 2