A Dijous 26 Gener 2006 18:24, Russel Howe va escriure: > A little more information, I reduced the number of times the vlarray > is summed to 4 and ran the test program in valgrind. The relevant > errors seem to be > > ==28085== 101294136 bytes in 2005 blocks are possibly lost in loss > record 39 of 40 > ==28085== at 0x1B9042FC: malloc (in /usr/lib/valgrind/ > vgpreload_memcheck.so) > ==28085== by 0x1C73528D: test_vltypes_alloc_custom (H5VLARRAY.c:33) > ==28085== by 0x1BFCE92A: H5T_vlen_seq_mem_write (H5Tvlen.c:451) > ==28085== by 0x52BFD1AF: ??? > ==28085== > ==28085== > ==28085== 289279580 (288541620 direct, 737960 indirect) bytes in 5782 > blocks are definitely lost in loss record 40 of 40 > ==28085== at 0x1B9042FC: malloc (in /usr/lib/valgrind/ > vgpreload_memcheck.so) > ==28085== by 0x1C73528D: test_vltypes_alloc_custom (H5VLARRAY.c:33) > ==28085== by 0x1BFCE92A: H5T_vlen_seq_mem_write (H5Tvlen.c:451) > ==28085== by 0x52BFD1AF: ??? > ==28085== > > I am still trying to figure out why the backtrace cuts off, but using > gdb, it appears that the call originates in H5VLARRAYread H5VLARRAY.c > line 501. This is in _readArray in hdf5Extension.pyx:1951. I think > the leaked data is rdata[i].p since PyBuffer_FromReadWriteMemory does > no memory management. The documentation for numarray.array indicates > that it makes a copy by default, but I haven't figure out when it is > safe to free the memory, any attempt I have made causes a segfault in > the sum ufunc, indicating that either the documentation is wrong or > the copy is lazy. Any hints?
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 (?). 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. Cheers, -- >0,0< Francesc Altet http://www.carabos.com/ V V Cárabos Coop. V. Enjoy Data "-" ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 _______________________________________________ Pytables-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/pytables-users
