Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

slice() leaks memory when part of a cycle #70846

Closed
KevinModzelewski mannequin opened this issue Mar 28, 2016 · 3 comments
Closed

slice() leaks memory when part of a cycle #70846

KevinModzelewski mannequin opened this issue Mar 28, 2016 · 3 comments
Labels
interpreter-core (Objects, Python, Grammar, and Parser dirs) performance Performance or resource usage

Comments

@KevinModzelewski
Copy link
Mannequin

KevinModzelewski mannequin commented Mar 28, 2016

BPO 26659
Nosy @birkenfeld, @pitrou, @vstinner, @benjaminp, @1st1, @serprex

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 = None
closed_at = <Date 2016-04-16.21:54:40.705>
created_at = <Date 2016-03-28.20:07:30.598>
labels = ['interpreter-core', 'performance']
title = 'slice() leaks memory when part of a cycle'
updated_at = <Date 2016-04-16.22:52:29.780>
user = 'https://bugs.python.org/KevinModzelewski'

bugs.python.org fields:

activity = <Date 2016-04-16.22:52:29.780>
actor = 'martin.panter'
assignee = 'none'
closed = True
closed_date = <Date 2016-04-16.21:54:40.705>
closer = 'python-dev'
components = ['Interpreter Core']
creation = <Date 2016-03-28.20:07:30.598>
creator = 'Kevin Modzelewski'
dependencies = []
files = []
hgrepos = []
issue_num = 26659
keywords = []
message_count = 3.0
messages = ['262582', '262589', '263590']
nosy_count = 8.0
nosy_names = ['georg.brandl', 'pitrou', 'vstinner', 'benjamin.peterson', 'python-dev', 'yselivanov', 'Kevin Modzelewski', 'Demur Rumed']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'resource usage'
url = 'https://bugs.python.org/issue26659'
versions = ['Python 2.7', 'Python 3.5', 'Python 3.6']

@KevinModzelewski
Copy link
Mannequin Author

KevinModzelewski mannequin commented Mar 28, 2016

The slice type doesn't participate in GC, which means that if you happen to create a cycle involving a slice, that cycle will never get freed. Here's an example:

def f():
    l = []
    l.append(slice(l))
# Will consume memory without bound:
while True:
    f()

This seems pretty hard to trigger accidentally, so it might not be a huge deal -- especially since it seems to have been around for a while. (I only checked 2.7 and trunk though.)

I think this could be solved by either having the slice class participate in GC (ie add tp_traverse and tp_clear methods), or maybe doing some type-filtering during slice_new().

@KevinModzelewski KevinModzelewski mannequin added interpreter-core (Objects, Python, Grammar, and Parser dirs) performance Performance or resource usage labels Mar 28, 2016
@serprex
Copy link
Mannequin

serprex mannequin commented Mar 29, 2016

Implementing tp_traverse & tp_clear seems to runs into complications due to slice_cache

@python-dev
Copy link
Mannequin

python-dev mannequin commented Apr 16, 2016

New changeset 879da9400529 by Benjamin Peterson in branch '2.7':
add gc support to slice (closes bpo-26659)
https://hg.python.org/cpython/rev/879da9400529

New changeset 9e2176d18965 by Benjamin Peterson in branch '3.5':
add gc support to slice (closes bpo-26659)
https://hg.python.org/cpython/rev/9e2176d18965

New changeset 870fcc50f1bd by Benjamin Peterson in branch 'default':
merge 3.5 (bpo-26659)
https://hg.python.org/cpython/rev/870fcc50f1bd

@python-dev python-dev mannequin closed this as completed Apr 16, 2016
@ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
interpreter-core (Objects, Python, Grammar, and Parser dirs) performance Performance or resource usage
Projects
None yet
Development

No branches or pull requests

0 participants