[Mono-dev] Handling StackOverflow, OutOfMemory, ThreadAbortException

[Rodrigo Kumpera]

On Wed, Feb 1, 2012 at 12:22 PM, Miguel Mudge
<michael.mudge at welchallyn.com>wrote:

> Yes, it's got machine exceptions.  With the help of the MMU, we are able
> to detect when the stack is down to the last 64K, so there is no need for
> an alternate stack.  We can call a function from there, somewhat akin to
> signals.


On which stack and thread is that function called? You obviously can't call
it on the overflown one.


> The requirements are that:
> - The native code is allowed to continue execution.
> - The managed code throws a StackOverflowException that executes finally
> blocks.
> - The root AppDomain continues running.
>
> As I understand it, the stack overflow handling in Mono only works on
> certain OSes and doesn't satisfy all of our requirements.  It also seems
> that the ThreadAbortException handling satisfies all of these requirements,
> so that code would be an architecturally appropriate place to handle both.
>

Well, the thread abort machinery was devised to handle async exceptions
started from a foreign thread. You can definitely use the low level
machinery to implement
stack overflow on your target. I would be willing to merge changes that
improve the low level bits and stack overflow handling to enable such a
thing, but there's no
reason to butcher the thread abort specific bits just for a quick hack.

As I told you before, I can't make an informed comment until you give a
better picture of how exactly a stack overflow is handled on your RTOS.

Mono OVF code uses soft guard pages to enable native to continue once we
reach a soft limit in stack usage so we can safely finish processing and
raise a
managed exception. But once it hits the hard limit while in native code,
the only viable option is to abort.


> The out-of-memory exception is almost the exact same story... When memory
> gets low, I want to be able to do something that allows native code to
> continue, but OutOfMemoryException is thrown when execution returns to
> managed code.  I assume there is no mechanism in there for this?
>

OOM is quite a different beast, it's handled synchronously since we know
exactly when we're out of managed memory. Mono doesn't handle native
allocation failures
well and this is something I would love to see patches for. Managed
allocation failures are well handled with sgen.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20120201/36dc76f4/attachment.html>