Missing [HandleProcessCorruptedStateExceptions]

[ayende]

I've code that may access invalid memory location. In the full .NET, I have [HandleProcessCorruptedStateExceptions] to mark such a code and recover from it. Is there such a way to handle it in the CoreCLR?

[morganbr]

@ayende, can you please tell us more about the scenario where you'd like to do that? We generally consider it a very dangerous practice to recover from corrupted state as it can make security attacks significantly easier.

[ayende]

Sure, here is my scenario:

https://github.com/ayende/ravendb/blob/master/Raven.Database/Indexing/LuceneCodecDirectory.cs#L180

Consider the case of memory mapping a file, and an API that is used to access it. Now, someone is disposing the class, so we unmap the file. However, some other code is still using this file, and expects to ObjectDisposedException when it happens.

This is stupid behavior, on many levels, but this is an existing codebase that we want to move.

[ctemple]

i think i got same question code like this catch exception on windows/.net 4.6.1,this is good but crash on windows/dotnetcore 2.0,this is not good need this feature to handle golang dll defer recover() functions

    [DllImport("kernel32.dll")]
    static extern void GetCurrentDirectory(int length, string dir);

    static void foo()
    {
        GetCurrentDirectory(256, null);
    }

    [HandleProcessCorruptedStateExceptions]
    static void boo()
    {
        try
        {
            foo();
        }
        catch (AccessViolationException ex)
        {
            Console.WriteLine("boo - {0}", ex.Message);
        }
    }

[danmoseley]

@jkotas is HandleProcessCorruptedStateExceptions likely to be supported on coreclr?

[jkotas]

Handling dirty access violations is not going to be supported. It is significant security risk as @morganbr described, and it is impossible to do cross-platform reliably.

@ctemple Could you please share more details on how you would like to use this for golang dll defer recover() functions?

[ayende]

@jkotas The problem for me is memory mapped system. If I get an error there (for example a network file mmap with network lost) I would really like to not have the entire cluster crash.

[jkotas]

The memory mapped files are interesting case. We may want to have register of memory mapped regions, and if there is a fault in managed code while accessing the registered memory region, convert it to exception and not fail fast. It works reliably only if you have a strong control over code accessing the memory mapped file. If you take the pointer and pass it to PInvoke (like in the above example) or to BCL function that happens to be implemented in C++, it would still fail fast - HandleProcessCorruptedStateExceptions on .NET Framework has the same problem.

[ayende]

I do have such strong control over this. And that would be wonderful for our purposes, yes. That would mean that I wouldn't have to protect all my methods, but just the memory regions in question.

[jkotas]

@morganbr What do you think about the memory mapped file case?

[morganbr]

Would it be possible for us to have MemoryMappedFile figure out whether something has been unmapped and avoid triggering the AV? I'm still very reluctant to expose HandleProcessCorruptedStateExceptions for general usage.

[ayende]

@morganbr For various reasons, we sometimes call to the native API directly, instead of going through MemoryMappedFile. It would be much better if we could have an API that would designate memory ranges as "turn an AV to an exception here".

[mikedn]

We should probably distinguish between "use after free" scenarios and "lost network" scenarios.

The former is dangerous and should not occur in correct code so it shouldn't be supported.

The later is not dangerous and it seems that at least on Windows it's relatively easy to handle - the exception code is EXCEPTION_IN_PAGE_ERROR instead of EXCEPTION_ACCESS_VIOLATION and the exception record contains the memory address that caused the exception, that can be passed to VirtualQuery to figure out that the address is within a mapped section. But if Unix like systems do not offer this kind of information then probably the only option is to manually communicate memory mapped ranges to the runtime.

[jkotas]

Would it be possible for us to have MemoryMappedFile figure out whether something has been unmapped and avoid triggering the AV?

Yes, the proposal is that the runtime is going to have a list of memory ranges where we turn the AV into exception.

[ayende]

Is there any progress around this are? I just run into an area where a mmap file had some bad sectors. When we tried to access some of then, an SEHException was thrown, obviously, and it killed the entire process.

[ayende]

I would be happy to send a PR for that if I that is fine and I can get some guidance on where to touch.

[jkotas]

The next steps that should happen for this:

• Submit API proposal to corefx (https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/api-review-process.md)
• Once the shape of the API is approved, implement it and expose the API.

[jkotas]

@ayende Would you be interested in crafting the API proposal?

[ayende]

@jkotas Yes, I can send that later today

[ayende]

Here it is: https://github.com/dotnet/corefx/issues/26513

[jkotas]

Duplicate of https://github.com/dotnet/runtime/issues/24767