Catching a hot potato

[Gor Gyolchanyan]

I see. That's what i said: overwritten allocated memory is the
hardest-to-find bug.
But you've shown me, that i can't possibly track down the misbehaving
module by catching a sigsegv.
There has to be a way to make thrid-party DLL usage safe and rid the
user from dunno-why crashes.
The user at least needs to know which DLL to throw away.
Any ideas how it could be achieved?

On Mon, Oct 17, 2011 at 4:54 PM, Steven Schveighoffer
<schveiguy at yahoo.com> wrote:
> On Mon, 17 Oct 2011 00:54:31 -0400, 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).
>
> sigsegv is often the *symptom*, not the *cause* of corrupted memory.
>
> Of course sigsegv cannot corrupt memory.  But corrupted memory often makes a
> segv occur (and quite often not anywhere near where the real problem is).
>
> It's why memory corruption is the *worst* bug to deal with.
>
> Your best bet is to close the application, and possibly print a stack trace.
>  Trying to continue is like continuing to drive when you get a flat tire.
>  You are just going to keep damaging your car!
>
> -Steve
>