This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

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.
History
Date User Action Args
2016-05-26 03:55:17ncoghlansetrecipients: + ncoghlan, gregory.p.smith, vstinner, yselivanov, abarry, Valentin David
2016-05-26 03:55:17ncoghlansetmessageid: <1464234917.2.0.452314417939.issue27122@psf.upfronthosting.co.za>
2016-05-26 03:55:17ncoghlanlinkissue27122 messages
2016-05-26 03:55:16ncoghlancreate