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.

classification
Title: Exception state lives too long in 3.0
Type: behavior Stage:
Components: Interpreter Core Versions: Python 3.0
process
Status: closed Resolution: fixed
Dependencies: Superseder: Lexical exception handlers
View: 3021
Assigned To: Nosy List: Rhamphoryncus, barry, benjamin.peterson, collinwinter, jyasskin, pitrou
Priority: critical Keywords: patch

Created on 2008-03-29 14:28 by pitrou, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
exc_cleanup.patch pitrou, 2008-03-29 14:35
exc_cleanup2.patch pitrou, 2008-03-29 23:23
exc_cleanup3.patch pitrou, 2008-05-02 20:27
exc_cleanup4.patch pitrou, 2008-05-07 22:41
better_exc_cleanup.patch pitrou, 2008-05-24 22:35
Messages (18)
msg64697 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) 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) * (Python committer) Date: 2008-03-29 14:35
And this is a patch, together with a test.
msg64734 - (view) Author: Jeffrey Yasskin (jyasskin) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) Date: 2008-05-02 20:27
A new patch with just an updated comment in ceval.c.
msg66344 - (view) Author: Collin Winter (collinwinter) * (Python committer) Date: 2008-05-06 23:26
Looks good to me. Antoine, do you have commit privileges?
msg66353 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2008-05-07 08:10
No, I don't.
msg66379 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) 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) * (Python committer) Date: 2008-05-08 04:26
r62847
msg66793 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) 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) * (Python committer) 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) * (Python committer) Date: 2008-05-24 12:27
For time being, should r62847 be reverted?
msg67296 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) 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) * (Python committer) Date: 2008-05-24 14:01
Patch removed, there are still some unsolved cases :-)
msg67311 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) 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) * (Python committer) Date: 2008-06-01 20:05
A clean solution is now proposed in #3021.
msg67990 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2008-06-11 16:04
Solved by r64121.
History
Date User Action Args
2022-04-11 14:56:32adminsetgithub: 46759
2008-06-11 16:04:10benjamin.petersonsetstatus: open -> closed
resolution: fixed
messages: + msg67990
2008-06-01 21:33:06benjamin.petersonsetsuperseder: Lexical exception handlers
2008-06-01 20:05:05pitrousetmessages: + msg67599
2008-05-30 20:33:14Rhamphoryncussetnosy: + Rhamphoryncus
2008-05-24 22:35:29pitrousetfiles: + better_exc_cleanup.patch
messages: + msg67311
2008-05-24 14:01:45pitrousetmessages: + msg67301
2008-05-24 14:00:17pitrousetfiles: - better_exc_cleanup.patch
2008-05-24 12:53:13pitrousetmessages: + msg67296
2008-05-24 12:27:08benjamin.petersonsetnosy: + benjamin.peterson
messages: + msg67293
2008-05-24 11:04:26pitrousetfiles: + better_exc_cleanup.patch
messages: + msg67291
2008-05-13 19:18:16collinwintersetstatus: closed -> open
assignee: collinwinter ->
resolution: fixed -> (no value)
2008-05-13 19:06:17pitrousetmessages: + msg66793
2008-05-08 04:26:58barrysetstatus: open -> closed
resolution: fixed
messages: + msg66403
priority: release blocker -> critical
2008-05-07 22:41:25pitrousetfiles: + exc_cleanup4.patch
messages: + msg66379
2008-05-07 08:11:05pitrousetmessages: + msg66353
2008-05-06 23:26:07collinwintersetmessages: + msg66344
2008-05-03 07:07:30georg.brandlsetpriority: critical -> release blocker
2008-05-02 20:27:37pitrousetfiles: + exc_cleanup3.patch
messages: + msg66108
2008-04-02 22:03:56barrysetpriority: release blocker -> critical
nosy: + barry
messages: + msg64883
2008-03-29 23:23:46pitrousetfiles: + exc_cleanup2.patch
messages: + msg64736
2008-03-29 22:50:56jyasskinsetassignee: collinwinter
messages: + msg64734
nosy: + collinwinter
2008-03-29 18:12:09christian.heimessetpriority: release blocker
2008-03-29 14:35:21pitrousetfiles: + exc_cleanup.patch
keywords: + patch
messages: + msg64698
2008-03-29 14:28:37pitroucreate