Yes. My own tests seems to indicate that you are right. I tend to think that numarray.array actually *does* the copy, but the question is why a subsequent free on rdata[i].p causes a segfault (?).
numarray does not copy. I traced the execution and found no place where copy occurs.
So I modified H5VLARRAYread to return these values, and made an explicit copy in _readArray, and then called H5Dvlen_reclaim at the end. No memory leak, no segfault, but I am not sure about the methods I used. I have attached a patch, what is the correct way to do this?Well, perhaps it would be worth the effort to have a try and use the standard way to get rid of the buffer "a la HDF5", namely, something like the call: H5Dvlen_reclaim(type_id, space_id, xfer_pid, data) *after* the numarray creation. However, this implies a refactoring of the VLArray._readArray in hdf5Extension.pyx because you need to access to the space_id and xfer_pid (you already have access to type_id and data in Pyrex space). Maybe you want to have a try at this.
patch
Description: Binary data
