This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: ctypes pointer not always keeping target alive
Type: behavior Stage:
Components: Extension Modules Versions: Python 3.3, Python 3.4, Python 2.7
Status: languishing Resolution:
Dependencies: Superseder:
Assigned To: theller Nosy List: arigo, r.david.murray, theller
Priority: normal Keywords:

Created on 2008-02-15 14:24 by arigo, last changed 2022-04-11 14:56 by admin.

File name Uploaded Description Edit arigo, 2008-02-15 14:24 failing test or bogus test? arigo, 2008-02-16 08:52
Messages (5)
msg62429 - (view) Author: Armin Rigo (arigo) * (Python committer) Date: 2008-02-15 14:24
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.
msg62436 - (view) Author: Thomas Heller (theller) * (Python committer) Date: 2008-02-15 20:00
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?
msg62453 - (view) Author: Armin Rigo (arigo) * (Python committer) Date: 2008-02-16 08:52
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, where I've put the
equivalent C code in comments.
msg84117 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2009-03-24 22:25
Thomas, do you accept this as a bug or should the issue be closed as
msg84218 - (view) Author: Thomas Heller (theller) * (Python committer) Date: 2009-03-26 21:04
I accept this as a bug; however I don't have time now to work on it.
Date User Action Args
2022-04-11 14:56:30adminsetgithub: 46376
2013-07-10 10:14:10christian.heimessetstatus: open -> languishing
versions: + Python 3.3, Python 3.4, - Python 3.1, Python 3.2
2010-09-20 16:39:49BreamoreBoysetversions: + Python 3.2, - Python 2.6, Python 3.0
2009-03-26 21:04:29thellersetmessages: + msg84218
2009-03-24 22:25:40r.david.murraysetpriority: normal
versions: + Python 2.6, Python 3.0, Python 3.1, Python 2.7
nosy: + r.david.murray

messages: + msg84117

type: behavior
2008-02-16 08:52:11arigosetfiles: +
messages: + msg62453
2008-02-15 20:00:13thellersetassignee: theller
messages: + msg62436
nosy: + theller
2008-02-15 14:24:58arigocreate