[Mono-dev] Handling StackOverflow, OutOfMemory, ThreadAbortException

[Rodrigo Kumpera]

What kind of machinery does your RTOS support? Something akin mach
exception ports?

Because you either need something like an exception port or sigaltstack to
handle stack overflows as it requires stack space anyways.

The way to implement this is to do the same logic as of altstack but from a
remote thread, I suppose.


On Tue, Jan 31, 2012 at 12:37 PM, Miguel Mudge <michael.mudge at welchallyn.com
> wrote:

> 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/20120201/1b8d13fe/attachment.html>