title: Why is a segmentation fault not recoverable?
body: <p>Following <a href="https://stackoverflow.com/q/70234212/913098">a previous question of mine</a>, most comments say &quot;just don't, you are in a limbo state, you have to kill everything and start over&quot;. <a href="https://stackoverflow.com/a/12824168/913098">There is also a &quot;safeish&quot; workaround</a>.</p>
  <p>What I fail to understand is <em><strong>why</strong></em> a segmentation fault is inherently nonrecoverable.</p>
  <p>The moment in which writing to protected memory is caught - otherwise, the <code>SIGSEGV</code> would not be sent.</p>
  <p>If the moment of writing to protected memory can be caught, I don't see why - in theory - it can't be reverted, at some low level, and have the SIGSEGV converted to a standard software exception.</p>
  <p>Please explain why after a segmentation fault the program is in an undetermined state, as very obviously, the fault is thrown <em>before</em> memory was actually changed (I am probably wrong and don't see why). Had it been thrown after, one could create a program that changes protected memory, one byte at a time, getting segmentation faults, and eventually reprogramming the kernel - a security risk that is not present, as we can see the world still stands.</p>
  <ol>
  <li>When exactly does a segmentation fault happen (= when is <code>SIGSEGV</code> sent)?</li>
  <li>Why is the process in an undefined behavior state after that point?</li>
  <li>Why is it not recoverable?</li>
  <li>Why does <a href="https://stackoverflow.com/a/12824168/913098">this solution</a> avoid that unrecoverable state? Does it even?</li>
  </ol>