The raw malloc/free calls inside the out-of-tree filters definitely broke with the develop branch. The buffer pointer allocated by the caller using H5MM_malloc(), and passed into H5Z_filter_zfp() with the expectation that it will be replaced with a newly allocated buffer of a different size, cannot be manipulated with raw free/malloc.
On Wed, Nov 8, 2017 at 12:32 PM, Jordan Henderson <[email protected]> wrote: > For ease of development I currently use the in-tree filters in my tests so I > haven't had to deal with the issue of H5MM_ vs raw memory routines inside > the filters, though I don't suspect this should make a difference anyway. > > > I had suspected that the underlying code might be approaching the write in a > different way and certainly this will need to be addressed. I am surprised > however that this kind of behavior hasn't been seen before, as it is legacy > code and should have still been hit in the library before my merge of the > new code during parallel HDF5 operations which did not use filters; this is > worth looking into. > > > I should be able to look into building HDF5 against PETSc with MVAPICH2, but > if there are any "gotchas" I should be aware of beforehand, please let me > know. Also, if you happen to run into any revelations on the behavior you're > seeing, I'd also be happy to discuss them and see what arises in the way of > a workable solution. > > _______________________________________________ Hdf-forum is for HDF software users discussion. [email protected] http://lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org Twitter: https://twitter.com/hdf5
