Catching a hot potato

[Gor Gyolchanyan]

If you overwrite your own memory (even partially), that's a bug of
equal severity as the segfault. In fact, it's a much worse bug, since
segfault is easy to miss and a silent memory overwrite is arguably one
of the hardest things to catch. That's why things like contracts,
invariants and unittests exist: to ensure correct logic.
Both the contracts and the sigsegv handler would do the same thing:
kick the DLL (or .so) out of the address space and go on doing
anything else, that still works (and prevent that DLL from being
loaded again, perhaps).
The worst thing, that could happen is, when the bad DLL overwrote
somethig in another (good) DLL. In which case the bad DLL would be
unloaded due to sigsegv handler and the good DLL would be unloaded due
to an invariant failure. Even if they are the only ones and the entire
app basically crashed, the difference is, that this way i can know for
sure, who's fault was the crash and the good DLL (despite it's
invariant failure) will be loaded next time (as opposed to the bad
one).
Taking good measures about a DLL with a faulty logic is better, then
just crashing completely without any idea why it happened.
The point is, that if a given app would support third-party extensions
as DLLs (for maximal performance), it shouldn't compromise the
stability of the app.

On Mon, Oct 17, 2011 at 9:37 AM, Andrew Wiley <wiley.andrew.j at gmail.com> wrote:
> On Sun, Oct 16, 2011 at 11:54 PM, Gor Gyolchanyan
> <gor.f.gyolchanyan at gmail.com> wrote:
>>
>> If the user tries to read unallocated memory, the memory can't
>> possibly get corrupted, since nothing is getting changed.
>> If the user tried to write to unallocated memory, the segfault should
>> _prevent_ it by throwing an OS-level exception (the sigsegv). Throwing
>> if _after_ the invalid write makes no sense. You can't save anything,
>> because your own data is not touched. Depending on the implementation,
>> either some other process's memory would be touched or nothing at all
>> (internally unmapped region).
>> I think the rumors of corrupted memory after sigsegv is boloney.
>> Otherwise the whole sigsegv idea is pointless (you could just as well
>> get terminated right away).
>
> The problem is that there's no guarantee that you *only* wrote outside your
> allocated virtual memory. You could have a bad pointer, overwrite half your
> program's data, then hit an invalid address and segfault. There are many
> scenarios in which bad writes *don't* cause segfaults (they may be
> incorrect, but they're still legal), so you can't really assume much about
> your program's state when you segfault.