[Mono-dev] Handling StackOverflow, OutOfMemory, ThreadAbortException

[Miguel Mudge]

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.

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.

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?

- Kipp

On Wed, Feb 1, 2012 at 8:21 AM, Rodrigo Kumpera <kumpera at gmail.com> wrote:

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