[wxPython-users] using wxImage in C++ python extension

[Josiah Carlson]

Christopher Barker <Chris.Barker at noaa.gov> wrote:
> Josiah Carlson wrote:
> > I should probably clarify a bit.
> 
> Thanks. I really hadn't followed that.
> 
> > The pointer that buffer b holds points
> > to memory that is no longer associated with any array object.  It may or
> > may not have been freed, which may or may not induce a segfault on
> > access.
> 
> I understand that better now.
> 
> However, if if there is still a reference to the buffer object, is that 
> memory still good? It looks like it is:
> 
>  >>> b[0]
> 'a'
>  >>> b[5]
> 'a'
> 
> That makes it look to me like the buffer object is responsible for that 
> memory, and if it's reference count > 0, then is will keep it around.

No.  The current implementation of buffer keeps a refcounted pointer to
the object it has a buffer of, as well as a second pointer to the data
(acquired via PyObject_AsBuffer() ).  The data pointer within the object
pointed to by buffer changes, and no buffers pointed to the object are
updated (to update them would violate various assumptions with how
buffers work). This is a long-known issue, and is a major problem with
how Python buffers currently work.  The only solution to this requires
having a realloc that warns you if it is going to allocate a new block,
or strictly over-allocating initially, only ever using malloc, and
creating a new data buffer object that holds memory used by array, etc.

The fact that the memory still has what you expect *now*, doesn't mean
it will in the future, nor does it mean that you will always be able to
access the memory without segfault.  Here's a sample that doesn't
segfault, but whose memory is not the same:

>>> import array
>>> a = array.array('B', 1024*'a')
>>> b = buffer(a)
>>> ia = a.buffer_info()[0]
>>> while ia == a.buffer_info()[0]:
...     a.extend(a)
...
>>> len(a)
2048
>>> b[:10]
' p~\x00 at p~\x00`p'
>>>

 - Josiah