[Mono-dev] Handling StackOverflow, OutOfMemory, ThreadAbortException
michael.mudge at welchallyn.com
Tue Jan 31 14:37:07 UTC 2012
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
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Mono-devel-list