msg64697 - (view) |
Author: Antoine Pitrou (pitrou) *  |
Date: 2008-03-29 14:28 |
See http://mail.python.org/pipermail/python-3000/2008-March/012830.html : the exception state can survive across thread switches if the enclosing frame is not destroyed immediately. |
|
|
msg64698 - (view) |
Author: Antoine Pitrou (pitrou) *  |
Date: 2008-03-29 14:35 |
And this is a patch, together with a test. |
|
|
msg64734 - (view) |
Author: Jeffrey Yasskin (jyasskin) *  |
Date: 2008-03-29 22:50 |
Thanks for the patch. This isn't specific to threads at all, so the test doesn't need to spawn a thread, just raise an exception from a nested function with a parameter, catch it, delete the object the parameter referred to, and then check that the object has been destroyed. I don't know the exception handling code very well, so I'd like someone more familiar with it to check that the patch is correct and efficient. Collin, would you do the honors? |
|
|
msg64736 - (view) |
Author: Antoine Pitrou (pitrou) *  |
Date: 2008-03-29 23:23 |
You are right, threads aren't needed. So, attaching an updated patch. |
|
|
msg64883 - (view) |
Author: Barry A. Warsaw (barry) *  |
Date: 2008-04-02 22:03 |
Knocking the priority down to critical for the next alpha release. This can be readdressed once the release is made. |
|
|
msg66108 - (view) |
Author: Antoine Pitrou (pitrou) *  |
Date: 2008-05-02 20:27 |
A new patch with just an updated comment in ceval.c. |
|
|
msg66344 - (view) |
Author: Collin Winter (collinwinter) *  |
Date: 2008-05-06 23:26 |
Looks good to me. Antoine, do you have commit privileges? |
|
|
msg66353 - (view) |
Author: Antoine Pitrou (pitrou) *  |
Date: 2008-05-07 08:10 |
No, I don't. |
|
|
msg66379 - (view) |
Author: Antoine Pitrou (pitrou) *  |
Date: 2008-05-07 22:41 |
Here is a last patch fixing without lines longer than 78 chars. |
|
|
msg66403 - (view) |
Author: Barry A. Warsaw (barry) *  |
Date: 2008-05-08 04:26 |
r62847 |
|
|
msg66793 - (view) |
Author: Antoine Pitrou (pitrou) *  |
Date: 2008-05-13 19:06 |
This bug should be reopened, the patch does not fix it when the except clause does not assign the exception to a local variable (that is, "except KeyError" rather than "except KeyError as e"). Another can of worms also appeared in #2833... |
|
|
msg67291 - (view) |
Author: Antoine Pitrou (pitrou) *  |
Date: 2008-05-24 11:04 |
This is a complementary patch that should fix the remaining cases (funnily doctest was relying on the old behaviour). Unfortunately #2833 still remains, and would probably need some discussion on the ML for proper resolution. |
|
|
msg67293 - (view) |
Author: Benjamin Peterson (benjamin.peterson) *  |
Date: 2008-05-24 12:27 |
For time being, should r62847 be reverted? |
|
|
msg67296 - (view) |
Author: Antoine Pitrou (pitrou) *  |
Date: 2008-05-24 12:53 |
I don't think so. As Amaury pointed in #2833, the original re-raising behaviour which got changed by fixing the present bug was rather broken in its own way. Anyway, I think the question better be asked on the ML because any solution for the re-raising behaviour will require some significant trickery in the compiler and the eval loop. |
|
|
msg67301 - (view) |
Author: Antoine Pitrou (pitrou) *  |
Date: 2008-05-24 14:01 |
Patch removed, there are still some unsolved cases :-) |
|
|
msg67311 - (view) |
Author: Antoine Pitrou (pitrou) *  |
Date: 2008-05-24 22:35 |
Here is a hopefully complete patch using the same approach as before. However I'm now convinced that another approach would be better in order to solve both this bug and the various re-raising issues. It would involve replacing most of the set_exc_info() / reset_exc_info() mechanism in ceval.c with something different, probably based on saving/restoring exception state values onto/from the frame stack. Problem is, I'm not sure I'll have time for it very soon. |
|
|
msg67599 - (view) |
Author: Antoine Pitrou (pitrou) *  |
Date: 2008-06-01 20:05 |
A clean solution is now proposed in #3021. |
|
|
msg67990 - (view) |
Author: Benjamin Peterson (benjamin.peterson) *  |
Date: 2008-06-11 16:04 |
Solved by r64121. |
|
|