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 < [email protected]> 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:* [email protected] [mailto: > [email protected]] *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 <[email protected]> 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 > [email protected] > http://www.stackless.com/mailman/listinfo/stackless >
_______________________________________________ Stackless mailing list [email protected] http://www.stackless.com/mailman/listinfo/stackless
