[Mono-dev] Handling StackOverflow, OutOfMemory, ThreadAbortException

[Rodrigo Kumpera]

On Tue, Feb 7, 2012 at 9:31 PM, Miguel Mudge
<michael.mudge at welchallyn.com>wrote:

> So I decided to add a pending_exception field to the thread object, but
> it's already there!
>
> mono_set_pending_exception sets the pending_exception field, but it
> looksit is never called, ever... It looks very much like what I was
> intending on adding.
>

The pending exception machinery was never finished, unfortunately.

The idea is to switch away from raising the exception directly in native
code to set the pending field and let the transition code do it.


>
> It looks like it's partially implemented for AMD64 only - I propose
> stripping the related calls from exceptions-amd64.c,
> and have mono_thread_execute_interruption
> return mono_thread_get_and_clear_pending_exception() somewhere near the end.
>

If you are willing to finish the work for amd64, it would be much welcome.


>
> In the general case, native programs can just call
> mono_set_pending_exception() if doesn't want to unwind right away.  In my
> case, malloc can call it when memory gets low, and our equivalent of
> SIGUSR1 can call it before calling
> mono_thread_current_check_pending_interrupt.
>

The async exception machinery needs some cleanup, I take that as granted.
So any change must be in the direction of simplifying it and not adding
extra complexity.


>
> Thoughts?
>
> - Kipp
> PS. thread->thread_interrupt_requested would need to be set
> by mono_set_pending_exception.  mono_thread_notify_pending_exc_fn
> and mono_threads_install_notify_pending_exc would need to be factored out.
>

I rather go with a model where setting a pending exception and kick
unwinding at the transition. It's safer and allow us to use stack/return
address patching to make it
efficient - transition must be as fast as possible since it's quite
frequent.

It would be very nice if you're willing to do this work and post it on a
public branch so we can later merge it. This can't be merged in the next
couple month as we're stabilizing trunk to get ready for 2.12, but I doubt
it will be ready in a shorter time than this.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20120208/f1900371/attachment.html>