Catching a hot potato

[Andrew Wiley]

On Mon, Oct 17, 2011 at 12: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.
>

Also:
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.
>

But you'll still get a segv. Read on.


> 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).
>

It doesn't depend on the implementation. A virtual memory system that allows
one process to write to another process's memory is worthless in many
respects (not quite all, but still).
A segv doesn't occur because you tried to write to the wrong place, it
happens when you try to write to a virtual address that hasn't been mapped
into your process's address space. Once a page is mapped in, the OS provides
no safety against overwriting your own data by accident or overwriting
malloc's data structures.
So yes, it doesn't just make no sense to throw the exception after the
write, it's impossible. Where would the write go in physical memory? If
there's no virtual page -> physical page mapping, that question can't be
answered (hence the segfault).


> 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 isn't really designed explicitly to catch your program when things
go wrong, it's designed to handle what happens when your program asks the
hardware/OS to do something it can't possibly do. It generally works because
most of the virtual address space will generally be unmapped, but the reason
things like SafeD and languages designed around the absence of pointers
exist is that you can silently break things in subtle ways with pointers and
not find out immediately what's going wrong.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20111017/b947ac7f/attachment.html>