Message266406
| Author |
ncoghlan |
| Recipients |
Valentin David, abarry, gregory.p.smith, ncoghlan, vstinner, yselivanov |
| Date |
2016年05月26日.03:55:16 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1464234917.2.0.452314417939.issue27122@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
Experimenting with this locally, it looks like the C level hang is indeed due to #25782, but the fact that we're implicitly trying to do "exc.__context__ = exc" is a new bug in _GeneratorContextManager introduced by the PEP 479 changes.
However, I'm now wondering whether that's also revealed a more general oversight in ExitStack's "_fix_exception_context" internal helper function: it's not explicitly handling the case where an __exit__ method re-raises the exception that was passed in, rather than returning a false value (indicating to the context management machinery that it should re-raise the original exception). I just hadn't noticed that before since all stdlib context managers are well-behaved in that regard (modulo bugs like the PEP 479 one).
Some failed attempts to create a simpler reproducer than Victor's last example show it isn't straightforward to get the current code to misbehave, but an upfront check for "new_exc is old_exc" may still be a worthwhile defensive coding measure. |
|