UNCLASSIFIED Thanks. It's unfortunate that HDF-5 does not support nested committed data types.
I may have discovered why the test is entering an infinite loop. It is actually a problem with the test. When the second call to if(H5Tcommitted(reopened_strtype) != 1) TEST_ERROR fails, it jumps to the end where it closes "strtype" and "cmptype" - both of which are already closed. If I set these handles to -1 when they are closed mid-way through the test, no infinite loop occurs. I suspect it is not valid to close a handle twice in HDF and so there is a logical error with the test code. I will send through a new patch later on. I guess I can accept that HDF-5 does not support nested committed data types, however the behaviour of H5Tcommitted() is clearly inconsistent depending on whether you have closed and reopened the file or not. The super-type currently says it *is* committed in the first part of the test. Would it be reasonable to restrict the bug report then to say that H5Tcommitted() should return 0 both before and after reopening the file? When designing our application it would have been useful if the HDF documentation stated this limitation. We may have designed it differently if we knew. Can I request a feature enhancement issue also be created in JIRA also for "adding support for nested committed data types"? The use case is for something similar to H5view but where the views available for a data type (including the types of elements of an array and members of a compound) depend on the *name* of the data type (not the name of the field). So, an array of 3x floating-point values might have a committed name "position" and another otherwise identical data type might have committed name "velocity" - the viewer application would treat them differently. Our work-around is to use metadata attributes on the top-level committed data type and then separately and recursively open each committed super-type. In terms of our application crash, my colleague has been debugging HDF while running in our application and may have found why it is crashing - and it is not this bug (which we thought it was). It is a different problem, and I'll hopefully submit a separate issue later on. We'll try and reproduce it in the HDF test harness in some detail before submitting. PS. Do you allow public access to your JIRA on-demand instance? Or is it for internal use only? Mark IMPORTANT: This email remains the property of the Department of Defence and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From: Hdf-forum [mailto:[email protected]] On Behalf Of Elena Pourmal Sent: Thursday, 19 March 2015 8:45 AM To: HDF Users Discussion List Subject: Re: [Hdf-forum] Bug in HDF-1.8.14 - Recursive named data types [SEC=UNCLASSIFIED] Mark, Thank you for the patch that illustrates the problem! It really saves a lot of investigation time! HDF5 doesn't support nested committed datatypes. In your example, when committed VL string is used as a member of the compound datatype, it is treated as a regular datatype. You can easily see it by using h5ls on the created dtypes1.h5 file. In the output below, cmp_type and str_type are shared (committed), but "vlstr" member of the cpm_type type is shown as a regular datatype. [epourmal@jam test]$ h5ls -v dtypes1.h5 Opened "dtypes1.h5" with sec2 driver. cmp_dset Dataset {3/3} Location: 1:1272 Links: 1 Storage: 12 logical bytes, 0 allocated bytes Type: shared-1:1176 struct { "vlstr" +0 variable-length null-terminated ASCII string } 4 bytes cmp_type Type Location: 1:1176 Links: 2 Type: shared-1:1176 struct { "vlstr" +0 variable-length null-terminated ASCII string } 4 bytes str_type Type Location: 1:800 Links: 1 Type: shared-1:800 variable-length null-terminated ASCII string When the second call to if(H5Tcommitted(reopened_strtype) != 1) TEST_ERROR is commented out, the infinite loop goes away. Hopefully, you can fix your application since the member of the committed compound datatype cannot be a committed datatype (even it was created using a committed one), but we still have an issue in HDF5. I confirmed that HDF5 1.8.* gives an infinite loop while HDF5 trunk is fine. It is not clear why the first H5committed call for the VL string type is not failing and why your test triggers an infinite loop. For you information I entered JIRA issue HDFFV-9174. Thanks again for your report! Elena ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Elena Pourmal The HDF Group http://hdfgroup.org 1800 So. Oak St., Suite 203, Champaign IL 61820 217.531.6112 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ On Mar 17, 2015, at 1:09 AM, Hodson, Mark (Contractor) <[email protected]<mailto:[email protected]>> wrote: <dtypes.c.patch>
_______________________________________________ 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
