Message266406
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. |
|
Date |
User |
Action |
Args |
2016-05-26 03:55:17 | ncoghlan | set | recipients:
+ ncoghlan, gregory.p.smith, vstinner, yselivanov, abarry, Valentin David |
2016-05-26 03:55:17 | ncoghlan | set | messageid: <1464234917.2.0.452314417939.issue27122@psf.upfronthosting.co.za> |
2016-05-26 03:55:17 | ncoghlan | link | issue27122 messages |
2016-05-26 03:55:16 | ncoghlan | create | |
|