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.

Sign up for GitHub

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

Jump to bottom

Python segfaults when freeing "deep" objects #40113

Closed
exarkun mannequin opened this issue Apr 1, 2004 · 8 comments
Closed

Python segfaults when freeing "deep" objects #40113

exarkun mannequin opened this issue Apr 1, 2004 · 8 comments
Labels
interpreter-core (Objects, Python, Grammar, and Parser dirs)

Comments

@exarkun
Copy link
Mannequin

exarkun mannequin commented Apr 1, 2004

BPO 927248
Nosy @loewis, @doerwalter, @birkenfeld, @hyeshik

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 2006-07-03.13:48:56.000>
created_at = <Date 2004-04-01.04:07:17.000>
labels = ['interpreter-core']
title = 'Python segfaults when freeing "deep" objects'
updated_at = <Date 2006-07-03.13:48:56.000>
user = 'https://bugs.python.org/exarkun'

bugs.python.org fields:

activity = <Date 2006-07-03.13:48:56.000>
actor = 'loewis'
assignee = 'none'
closed = True
closed_date = None
closer = None
components = ['Interpreter Core']
creation = <Date 2004-04-01.04:07:17.000>
creator = 'exarkun'
dependencies = []
files = []
hgrepos = []
issue_num = 927248
keywords = []
message_count = 8.0
messages = ['20405', '20406', '20407', '20408', '20409', '20410', '20411', '20412']
nosy_count = 7.0
nosy_names = ['loewis', 'doerwalter', 'georg.brandl', 'jimjjewett', 'exarkun', 'hyeshik.chang', 'smulloni']
pr_nums = []
priority = 'high'
resolution = 'fixed'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue927248'
versions = ['Python 2.3']
@exarkun
Copy link
Mannequin Author

exarkun mannequin commented Apr 1, 2004

An example to produce this behavior:

>>> f = lambda: None
>>> for i in range(1000000):
...     f = f.__call__
... 
>>> f = None
Segmentation fault

@exarkun exarkun mannequin closed this as completed Apr 1, 2004
@exarkun exarkun mannequin added the interpreter-core (Objects, Python, Grammar, and Parser dirs) label Apr 1, 2004
@hyeshik
Copy link
Contributor

hyeshik commented Apr 1, 2004

Logged In: YES
user_id=55188

Oh. my patch doesn't fix another scenario that using
recursive by two or more types of slots. So I remove.

@jimjjewett
Copy link
Mannequin

jimjjewett mannequin commented Apr 5, 2004

Logged In: YES
user_id=764593

CVS for 2.4 has comments for (and a fix for) problems similar
to this. Does the bug still exist with that source code?

@smulloni
Copy link
Mannequin

smulloni mannequin commented Apr 8, 2004

Logged In: YES
user_id=108556

Python CVS as of April 7th consistently segfaults with the
above example for me:

smulloni@bracknell src $ ~/apps/python-cvs/bin/python
Python 2.4a0 (#1, Apr  7 2004, 23:10:34) 
[GCC 3.3.2 20031218 (Gentoo Linux 3.3.2-r5,
propolice-3.3-7)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> f=lambda: None
>>> for x in xrange(1000000):
...     f=f.__call__
... 
>>> f=None
Segmentation fault

Of course, maybe that's a good thing :).

@doerwalter
Copy link
Contributor

Logged In: YES
user_id=89016

Python CVS from 2004-06-02 seems to work:
Python 2.4a0 (#5, Jun  2 2004, 20:23:30) 
[GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-113)] on linux2
Type "help", "copyright", "credits" or "license" for more 
information.
>>> f = lambda: None
>>> for x in xrange(1000000):
...  f = f.__call__
... 
>>> f
<method-wrapper object at 0x4259478c>
>>> f = None
>>> f
>>>

@birkenfeld
Copy link
Member

Logged In: YES
user_id=1188172

CVS HEAD of 2006/01/10 still segfaults (here GCC 3.4.5).

Segfault occurs at wrapper_dealloc in descrobject.c.

@exarkun
Copy link
Mannequin Author

exarkun mannequin commented Jan 10, 2006

Logged In: YES
user_id=366566

Note that in doerwalter transcript, _ is still bound to the
method wrapper, preventing Python from attempting to free it.

@loewis
Copy link
Mannequin

loewis mannequin commented Jul 3, 2006

Logged In: YES
user_id=21627

This is now fixed in r47217 and r47218, by putting the
method-wrapper objects into the trashcan.

@ezio-melotti ezio-melotti transferred this issue from another repository Apr 9, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
interpreter-core (Objects, Python, Grammar, and Parser dirs)
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@birkenfeld @doerwalter @hyeshik