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

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