Skip to content

ctypes pointer not always keeping target alive #46376

Open
#108519
Open
ctypes pointer not always keeping target alive#46376
#108519
Assignees
theller
Labels
extension-modulesC modules in the Modules dirtopic-ctypestype-bugAn unexpected behavior, bug, or error

Description

@arigo
arigo
mannequin
opened on Feb 15, 2008
BPO 2123
Nosy @arigo, @theller, @bitdancer
Files
  • x.py: failing test or bogus test?
  • y.py
    		•

    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/theller'
closed_at = None
created_at = <Date 2008-02-15.14:24:58.157>
labels = ['extension-modules', 'type-bug']
title = 'ctypes pointer not always keeping target alive'
updated_at = <Date 2013-07-10.10:14:10.589>
user = 'https://github.com/arigo'

    bugs.python.org fields:

    activity = <Date 2013-07-10.10:14:10.589>
actor = 'christian.heimes'
assignee = 'theller'
closed = False
closed_date = None
closer = None
components = ['Extension Modules']
creation = <Date 2008-02-15.14:24:58.157>
creator = 'arigo'
dependencies = []
files = ['9436', '9438']
hgrepos = []
issue_num = 2123
keywords = []
message_count = 5.0
messages = ['62429', '62436', '62453', '84117', '84218']
nosy_count = 3.0
nosy_names = ['arigo', 'theller', 'r.david.murray']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'languishing'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue2123'
versions = ['Python 2.7', 'Python 3.3', 'Python 3.4']

    Linked PRs

    Activity

    1. arigo commented on Feb 15, 2008

      @arigo
      arigomannequin
      on Feb 15, 2008
      MannequinAuthor

      It's hard to tell for sure, given the lack of precise definition, but I
      believe that the attached piece of code "should" work. What it does is
      make p1 point to c_long(20). So ctypes should probably keep the
      c_long(20) alive as long as p1 is alive (and not further modified).
      This test shows that the c_long(20) gets freed instead, making the
      p1.contents reference garbage.

    2. arigo
      added
      extension-modulesC modules in the Modules dir
      on Feb 15, 2008

    3. theller commented on Feb 15, 2008

      @theller
      theller
      on Feb 15, 2008

      May I ask: do you have a real use case for this, or is it a carefully
      constructed example?

      Of course I take all the blame for not defining/documenting this
      stuff. My current view is this:

      Python code C code
      ======================= ================

      ptr = POINTER(c_long)()         int *ptr = NULL;
x = c_long(42)                  int x = 42;

ptr.contents = x                ptr = &x;

a = ptr[0]                      int a = *ptr;
b = ptr[n]                      int b = ptr[n];

      Assigning to .contents changes 'where the pointer points to'.
      __setitem__ changes the pointed to memory location; __getitem__
      retrieves the pointed to memory location.

      Having said that, it is no longer clear to me what reading the
      .contents attribute should mean. Would making the .contents attribute
      write-only help - is it impossible to construct this 'bug' without
      assigning to .contents?

    4. theller
      self-assigned this
      on Feb 15, 2008

    5. arigo commented on Feb 16, 2008

      @arigo
      arigomannequin
      on Feb 16, 2008
      MannequinAuthor

      We're finding such bugs because we are trying to reimplement ctypes in PyPy.

      I guess your last question was "is it impossible to construct this 'bug'
      without *reading* .contents?". The answer is that it doesn't change
      much; you can replace all the reads from .contents with reads from [0],
      and still see the issue. See attached y.py, where I've put the
      equivalent C code in comments.

    6. bitdancer commented on Mar 24, 2009

      @bitdancer
      bitdancer
      on Mar 24, 2009
      Member

      Thomas, do you accept this as a bug or should the issue be closed as
      invalid?

    7. bitdancer
      added
      type-bugAn unexpected behavior, bug, or error
      on Mar 24, 2009

    8. theller commented on Mar 26, 2009

      @theller
      theller
      on Mar 26, 2009

      I accept this as a bug; however I don't have time now to work on it.

    9. tiran
      added
      staleStale PR or inactive for long period of time.
      on Jul 10, 2013
    10. ezio-melotti
      transferred this issue fromon Apr 10, 2022
    11. serhiy-storchaka
      added this to Locale issues 🗺on May 21, 2022
    12. serhiy-storchaka
      added
      topic-ctypes
      on May 21, 2022
    13. serhiy-storchaka
      removed this from Locale issues 🗺on May 21, 2022

    14. ambv commented on Jul 22, 2023

      @ambv
      ambv
      on Jul 22, 2023
      Contributor

      This looks like it works as expected at least as of Python 3.7 where c_long(20) is indeed preserved and p1.contents removes 20 as expected.

    15. code-of-kpp commented on Jul 22, 2023

      @code-of-kpp
      code-of-kpp
      on Jul 22, 2023
      Contributor

      Original examples would pass, but only because of gc delay.

      Here's fun way to demonstrate that the problem still exists (and can be converted to a test):

      import ctypes
import weakref

p1 = ctypes.pointer(ctypes.c_long(10))
w = weakref.WeakValueDictionary()
ctypes.pointer(p1).contents.contents = w.setdefault(
    1, ctypes.c_long(-1),
)
assert p1.contents.value == -1
assert 1 in w

    16. 24 remaining items

    17. code-of-kpp
      added 2 commits that reference this issue on Aug 27, 2023

      pythongh-46376: add (failing) tests for ctypes/pointer/cast/set_contents

      3e346a8

      pythongh-46376: add (failing) tests for ctypes/pointer/cast/set_contents

      5dbb4ae

    18. vstinner commented on Aug 30, 2023

      @vstinner
      vstinner
      on Aug 30, 2023
      Member

      This should be re-opened, as fix in 3.11 was reverted and the one in 3.12/3.13/main isn't working always

      Right, see issue #107940 which is a Python 3.12 regression.

      In the 3.12 branch, I confirm that the commit 54aaaad introduced the regression: issue #46376 of PR #107487 (backport of PR #107131).

    19. vstinner
      added a commit that references this issue on Aug 30, 2023

      Revert "pythongh-46376: Return existing pointer when possible in ctyp…

      8ae78bf

    20. code-of-kpp commented on Aug 31, 2023

      @code-of-kpp
      code-of-kpp
      on Aug 31, 2023
      Contributor

      Please, take a look at
      #108519

    21. ambv
      added a commit that references this issue on Sep 4, 2023

      Revert "gh-46376: Return existing pointer when possible in ctypes (#1… (

      5a79d2a
    22. ambv
      reopened this on Sep 4, 2023
    23. ambv
      added a commit that references this issue on Sep 4, 2023

      Revert "[3.12] pythongh-46376: Return existing pointer when possible …

      a6f728d
    24. hugovk
      added a commit that references this issue on Sep 4, 2023

      Revert "pythongh-46376: Return existing pointer when possible in ctyp…

      140a165
    25. ambv
      added a commit that references this issue on Sep 4, 2023

      [3.12] gh-46376: Revert "Return existing pointer when possible in cty…

      e0f6080
    26. code-of-kpp
      added 3 commits that reference this issue on Sep 6, 2023

      pythongh-46376: add (failing) tests for ctypes/pointer/cast/set_contents

      972c50f

      pythongh-46376: add (failing) tests for ctypes/pointer/cast/set_contents

      d44a269

      pythongh-46376: add (failing) tests for ctypes/pointer/cast/set_contents

      b6e92ba
    27. serhiy-storchaka
      added this to Ctypes issueson Jan 1, 2024
    28. code-of-kpp
      added a commit that references this issue on Aug 22, 2025

      pythongh-46376: minimal fix for setting pointers via pointers in ctypes

      a42ad21
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

    Metadata

    Metadata

    Assignees

    Labels

    extension-modulesC modules in the Modules dirtopic-ctypestype-bugAn unexpected behavior, bug, or error

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions