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

~Py_buffer.obj field is undocumented, though not hidden #54210

Closed
kermode mannequin opened this issue Sep 30, 2010 · 4 comments
Closed

~Py_buffer.obj field is undocumented, though not hidden #54210

kermode mannequin opened this issue Sep 30, 2010 · 4 comments
Labels
docs Documentation in the Doc dir

Comments

@kermode
Copy link
Mannequin

kermode mannequin commented Sep 30, 2010

BPO 10001
Nosy @mdickinson, @ncoghlan, @pitrou
Superseder
  • bpo-10181: Problems with Py_buffer management in memoryobject.c (and elsewhere?)
    		•
    Files
  • bufobj.c.gz: Embedded Python C program; crashes with Python 3.2a2
    		•

    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 2011-01-04.14:56:10.650>
created_at = <Date 2010-09-30.17:46:45.812>
labels = ['docs']
title = '~Py_buffer.obj field is undocumented, though not hidden'
updated_at = <Date 2011-01-04.14:56:10.648>
user = 'https://bugs.python.org/kermode'

    bugs.python.org fields:

    activity = <Date 2011-01-04.14:56:10.648>
actor = 'ncoghlan'
assignee = 'docs@python'
closed = True
closed_date = <Date 2011-01-04.14:56:10.650>
closer = 'ncoghlan'
components = ['Documentation']
creation = <Date 2010-09-30.17:46:45.812>
creator = 'kermode'
dependencies = []
files = ['19069']
hgrepos = []
issue_num = 10001
keywords = []
message_count = 4.0
messages = ['117754', '117770', '117780', '125330']
nosy_count = 5.0
nosy_names = ['mark.dickinson', 'ncoghlan', 'kermode', 'pitrou', 'docs@python']
pr_nums = []
priority = 'normal'
resolution = 'duplicate'
stage = 'needs patch'
status = 'closed'
superseder = '10181'
type = None
url = 'https://bugs.python.org/issue10001'
versions = ['Python 3.1', 'Python 2.7', 'Python 3.2']
    @kermode
    Copy link
    Mannequin Author

    kermode mannequin commented Sep 30, 2010

    Python 3.2a2+ (py3k:85072M, Sep 29 2010, 12:11:17) (from SVN)
    [GCC 4.4.5 20100728 (prerelease)] on linux2 (Debian squeeze)

    The ~Py_buffer.obj field is undocumented. Yet memoryview, that acts as a wrapper, includes the field in gc traversal. Also, if the field is not initialized by bf_getbuffer its value can be indeterminate. For memoryview the gc can crash (see attached C demo program).

    @kermode kermode mannequin added the interpreter-core (Objects, Python, Grammar, and Parser dirs) label Sep 30, 2010
    @pitrou
    Copy link
    Member

    pitrou commented Oct 1, 2010

    The recommended way is to use PyBuffer_FillInfo() (and then fill in any additional data if necessary), which will set the pointer and incref it itself.

    I agree all this is a bit poorly documented.

    @pitrou pitrou added docs Documentation in the Doc dir and removed interpreter-core (Objects, Python, Grammar, and Parser dirs) labels Oct 1, 2010
    @kermode
    Copy link
    Mannequin Author

    kermode mannequin commented Oct 1, 2010

    This will work for bf_getbuffer, though having PyObject_GetBuffer set
    the obj field before passing it to the callback might be safer. Also,
    this does not address the case with wrapper types like memoryview. What
    happens if ~Py_buffer.obj is not visited in tp_traverse? Should this be
    documented?

    @ncoghlan
    Copy link
    Contributor

    ncoghlan commented Jan 4, 2011

    Closing as a dupe of 10181, but transferring Lenard's comments over there.

    @ncoghlan ncoghlan closed this as completed Jan 4, 2011
    @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
    Assignees
    No one assigned
    Labels
    docs Documentation in the Doc dir
    Projects
    None yet
    Milestone
    No milestone
    Development

    No branches or pull requests
    2 participants
    @ncoghlan @pitrou