[Stackless] Patch to exception handler.

Gil Colgate gcolgate at gmail.com
Thu Apr 19 01:22:53 CEST 2012


You're welcome. We encountered this when a C function we called from python
called a library function that did an "OutputDebugStr", which basically
does an int-3 ... it prints the string by causing an exception that is
picked up by the debugger. This library had C++ exception handling with
some exceptions handled, but not the OutputDebugStr.

This could happen to anyone who is unfortunate to need to call precompiled
libraries written in C++ that use exception handling. I was able to paper
over the bug at first by compiling out the OutputDebugStr calls, but fixed
the bug seriously later.

On Tue, Apr 17, 2012 at 4:26 AM, Kristján Valur Jónsson <
kristjan at ccpgames.com> wrote:

>  I looked at this and I think it is probably ok.****
>
> The reason we were doing this messing with SEH code was not to support SEH
> In the context of stackless, but to make sure that we were not accidentally
> trampling any higher SEH in place when doing task switching.****
>
> As long as this patch does that, then we should be fine.****
>
> We should probably make sure that the “stub” never has any SEH handlers to
> begin with, so that an exception in a fresh tasklet doesn’t cause those to
> start to try to unwind the stack because it makes no sense.****
>
> ** **
>
> I’ll take another look and this and then get it committed when I find the
> time.  ****
>
> Thanks!****
>
> ** **
>
> K****
>
> ** **
>
> ** **
>
> ** **
>
> *From:* stackless-bounces at stackless.com [mailto:
> stackless-bounces at stackless.com] *On Behalf Of *Gil Colgate
> *Sent:* 16. apríl 2012 18:33
> *To:* The Stackless Python Mailing List
> *Subject:* Re: [Stackless] Patch to exception handler.****
>
> ** **
>
> Did this meet with anyone's approval?****
>
> On Mon, Apr 9, 2012 at 11:43 AM, Gil Colgate <gcolgate at gmail.com> wrote:**
> **
>
> Here is a fix for the exception handler, I included just the .patch.
>
>     This corrects the problems with python having a different exception
> the environment when the item is called again.
>
>     In the previous code, whenever a python tasklet was suspended the top
> of the exception chain was saved. This very well could be a pointer into
> code above the python stack into the main program. When the python tasklet
> is called again, it's stack is put back *in the same place*, but the
> environment above the stack *might be different*. This would cause the
> exception chain to screw up in the part where the exception chain points
> above the stack. This was the cause of the broken exception chain bug.
>
>
>     If a tasklet has none of it's own exception chains, we will discover
> this by reading the exception list and seeing that the address is above the
> stack, so we don't need to save or restore it it.
>
>     If, on the other hand, the tasklet has a chain we save it. When
> restoring it we look at the current chain and insert the chain from the
> restored stack into it at the appropriate spot, so that the tasklet's chain
> points correctly into it's parent's change.
>
>     Stack slicing: Stackless in general has a problem with stack slicing.
> This code will work in when the stack is sliced (I tested it with 2K stack
> slices and try-catches everywhere) but certain exceptions that belonged to
> inactive stack slices will not be executed since they are not currently
> linked into the chain.  ****
>
> ** **
>
> _______________________________________________
> Stackless mailing list
> Stackless at stackless.com
> http://www.stackless.com/mailman/listinfo/stackless
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.stackless.com/pipermail/stackless/attachments/20120418/0e10f8df/attachment.html>


More information about the Stackless mailing list