C++ – Protecting Memory from Segmentation Faults

cerror handlinglinux

How can one safely call a function that might segfault without corrupting the stack or the heap?

These SO questions cover using signal handlers and setjmp.h to regain control.

Coming back to life after Segmentation Violation

Best practices for recovering from a segmentation fault

They neglect the likely memory corruption that occurs prior to a seg fault.

What strategies can be used to isolate the memory space of a function and its caller?

This is just a curiosity question, there's no specific problem I'm trying to solve. Let's just suppose we're programming something that absolutely cannot crash — pacemaker, Mars orbiter, nuclear launch control, take your pick. We've already thoroughly unit tested all our code and formally proven its correctness. For bureaucratic reasons we have to use C++ and Linux.

I was trying to sketch this out with clone(). My idea was to run the function with as much isolation as possible and pass data back and forth by squirreling it away at the bottom of the child's stack.

Is that reasonable or is there a better way to do this?

Best Answer

The solution is a remote procedure call. The callee must run in its own process space. How exactly you achieve that is a fairly minor detail. I'd strongly suggest not inventing the wheel yourself.

Not that you'd need this after you've "formally proven its correctness". Correct code doesn't cause segfaults.

Related Solutions

C/C++ Stack Frame – Understanding Stack Frame of Function Call in C/C++

In addition to what Dirk said, an important use of stack frames is to save previous values of registers so that they can be restored after a function call. So, even on processors where registers are used for passing parameters, returning a value, and saving the return address, the values of those registers are saved on the stack before a function call so that they can be restored after the call. This allows one function to call another without overwriting its own parameters or forgetting its own return address.

So, calling a function B from function A on a typical "generic" system might involve the following steps:

function A:
- push space for the return value
- push parameters
- push the return address
jump to the function B
function B:
- push the address of the previous stack frame
- push values of registers that this function uses (so they can be restored)
- push space for local variables
- do the necessary computation
- restore the registers
- restore the previous stack frame
- store the function result
- jump to the return address
function A:
- pop the parameters
- pop the return value

This is by no means the only way function calls can work (and I may have a step or two out of order), but it should give you an idea of how the stack is used to let the processor handle nested function calls.

How to Protect from 0 Passed to std::string Parameters in C++

I don't think you should protect yourself. It's undefined behavior on the caller's side. It's not you, it's the caller who calls std::string::string(nullptr), which is what is not allowed. The compiler lets it be compiled, but it lets other undefined behaviors be compiled as well.

The same way would be getting "null reference":

int* p = nullptr;
f(*p);
void f(int& x) { x = 0; /* bang! */ }

The one who dereferences the null pointer is making UB and is responsible for it.

Moreover, you cannot protect yourself after undefined behavior has happened, because the optimizer is in its full right to assume that the undefined behavior had never happened, so the checks if c_str() is null can be optimized out.

Related Topic

C++ – Blocking Function Call with Asynchronous Content