[Mono-dev] Handling StackOverflow, OutOfMemory, ThreadAbortException

[Miguel Mudge]

I'm not specifically interested in the abort machinery, but looks like it's
in a good position to handle low of mem/stack.  Our RTOS also doesn't
support signals at all.  Are there better places to handle and recover from
low mem/stack?

- Kipp

On Tue, Jan 31, 2012 at 9:16 AM, Rodrigo Kumpera <kumpera at gmail.com> wrote:

> 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/67400814/attachment.html>