Repository navigation
Defer DECREFs until enum object is in a consistent state for re-entrancy #70678
Description
| BPO | 26491 |
|---|---|
| Nosy | @rhettinger, @vstinner, @serhiy-storchaka |
| PRs | |
| Files |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = 'https://github.com/rhettinger'
closed_at = <Date 2017-09-25.09:16:43.795>
created_at = <Date 2016-03-06.10:23:02.517>
labels = ['interpreter-core', 'type-bug', '3.7']
title = 'Defer DECREFs until enum object is in a consistent state for re-entrancy'
updated_at = <Date 2017-09-25.09:16:43.794>
user = 'https://github.com/rhettinger'bugs.python.org fields:
activity = <Date 2017-09-25.09:16:43.794>
actor = 'rhettinger'
assignee = 'rhettinger'
closed = True
closed_date = <Date 2017-09-25.09:16:43.795>
closer = 'rhettinger'
components = ['Interpreter Core']
creation = <Date 2016-03-06.10:23:02.517>
creator = 'rhettinger'
dependencies = []
files = ['42076']
hgrepos = []
issue_num = 26491
keywords = ['patch']
message_count = 6.0
messages = ['261246', '263284', '263289', '263301', '263307', '302933']
nosy_count = 3.0
nosy_names = ['rhettinger', 'vstinner', 'serhiy.storchaka']
pr_nums = ['3747']
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue26491'
versions = ['Python 3.7']
Activity
serhiy-storchaka commentedon Mar 6, 2016
I don't see possible bug here.
The first item of the tuple is always int or None. It's decrefing don't trigger executing user code.
The second item of the tuple is decrefed when the refcount of the tuple is 2 and we own all references. The code triggered by decrefing the old item can't use the tuple (since its refcount is not 1 now), nor free the new index or new item (since we take the ownership of them).
I think this patch is not needed.
vstinner commentedon Apr 12, 2016
Raymond: Do you have an example to trigger the issue?
vstinner commentedon Apr 13, 2016
Oh, this change was not intended. I don't know how it occurred.
rhettinger commentedon Apr 13, 2016
Deferring decrefs as late as possible is a good practice, reducing the risk of bugs being introduced later. There have been other places where there were bugs that arose due to premature decreffing.
I wrote the original code for enumerate, am the primary maintainer, and can make improvements to code organization as needed. Unless you think this change is broken, it should stay in.
serhiy-storchaka commentedon Apr 13, 2016
This change is not broken. It is just redundant.
If you are still inclined to apply this changes, I would suggest to factor out common code in enum_next_long and enum_next.
Any reply changes the status from pending to open.
rhettinger commentedon Sep 25, 2017
New changeset 8110dbd by Raymond Hettinger in branch 'master':
bpo-26491 Defer DECREFs until enumobject is in a consistent state (bpo-3747)
8110dbd