[Mono-dev] Handling StackOverflow, OutOfMemory, ThreadAbortException

[Rodrigo Kumpera]

Mono already handles that in the case of stack overflow by using
sigaltstack. Why do you want the abort machinery to raise anything but their
related abort exceptions?

On Mon, Jan 30, 2012 at 5:08 PM, Miguel Mudge
<michael.mudge at welchallyn.com>wrote:

> We've got a single-process RTOS running Mono and we've started to tackle
> what happens when a stack overflow or out of memory condition occurs.
>
> We're using an AppDomain to load and unload a variety of apps that come
> off the external flash drive.  When things go very wrong [StackOverflow or
> OutOfMemory], we terminate Mono entirely so the rest of the device can
> continue doing its job.
>
> We'd like to be able to more gracefully handle StackOverflow, OutOfMemory
> so that finally clauses execute and the root AppDomain can continue
> running.  As I understand it, mono_throw_exception() throws immediately,
> but since stack/memory runs out unexpectedly, it's best if we have some
> spare memory/stack so the native code can finish what it was doing before
> managed exception handling starts cleaning up the mess.  So - we're looking
> for behavior closer to ThreadAbortException.
>
> I see that in threads.c/mono_thread_execute_interruption(),
> thread->interruption_requested indicates that the ThreadAbortException
> should be thrown at the native->managed transition [among maybe some other
> actions].  I'm proposing that gets changed [or amended] to throw an
> arbitrary exception, both for future use and for our specific case.  Native
> code such as signal handlers would be able to cause an exception to be
> thrown only after execution returns to managed.  Our goal is to have
> several MB of guard pages (in spare memory and on the stack) available to
> handle the unwind.
>
> Comments?  Am I on the right track here?  Any forseen gotchas?
>
> - Kipp
>
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20120131/430964ac/attachment.html>