.NET H5GgetObjectNameByIndexException

I'm running into a strange bug that I can't wrap my head around.

I have a utility application/DLL that iterates through a folder of HDF5 files and extracts each dataset to csv. These files are generated with HDF5DotNet and HDF5 1.8.6 64 bit on a 64 bit machine. This build is well worn in 64 bit. Owing to a bunch of historic issues, the end user OSes are 32 bit. So the CSV exporter is 32 bit. When executing the 32 bit version of this exporter, I get a H5GgetObjectNameByIndexException. This happens sometime during the iteration, but it is inconsistent. It could start at any file in the sequence. It happens during my BuildDatasetList() which uses H5G.iterate to come up with a list of dataset names. Once it throws the exception, each successive file gets the same error, even though every HDF object is closed out properly. If I close the app and re-run, it starts ok and will randomly fail again somewhere in the file sequence.

The code is iterative; no conversion is going on in parallel. The HDF5 lib is built as threadsafe anyway. I rebuilt all the libraries from scratch and ran the ctests on the HDF libraries. Everything checked out. But the bug was still present.

On the 64 bit version of the exporter I run into none of this difficulty. 32 bit fails with both debug and release builds. All I get is the HDF5DotNet exception information: "Failed to find name of object in group # with index 0". The inputs all look fine. None of the HDF5-level error information is available.

Any thoughts?

Scott

···

________________________________

This e-mail and any files transmitted with it may be proprietary and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error please notify the sender. Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of Exelis Inc. The recipient should check this e-mail and any attachments for the presence of viruses. Exelis Inc. accepts no liability for any damage caused by any virus transmitted by this e-mail.

Scott, how are you? The (deprecated) H5Gget_objname_by_idx call has a size_t argument.
Could be a bug in the wrapper. (I haven't looked at the code.) Are you using an IntPtr?

G.

···

From: Hdf-forum [mailto:hdf-forum-bounces@lists.hdfgroup.org] On Behalf Of Mitchell, Scott - Exelis
Sent: Wednesday, May 20, 2015 2:35 PM
To: HDF Users Discussion List (hdf-forum@lists.hdfgroup.org)
Subject: [Hdf-forum] .NET H5GgetObjectNameByIndexException

I'm running into a strange bug that I can't wrap my head around.

I have a utility application/DLL that iterates through a folder of HDF5 files and extracts each dataset to csv. These files are generated with HDF5DotNet and HDF5 1.8.6 64 bit on a 64 bit machine. This build is well worn in 64 bit. Owing to a bunch of historic issues, the end user OSes are 32 bit. So the CSV exporter is 32 bit. When executing the 32 bit version of this exporter, I get a H5GgetObjectNameByIndexException. This happens sometime during the iteration, but it is inconsistent. It could start at any file in the sequence. It happens during my BuildDatasetList() which uses H5G.iterate to come up with a list of dataset names. Once it throws the exception, each successive file gets the same error, even though every HDF object is closed out properly. If I close the app and re-run, it starts ok and will randomly fail again somewhere in the file sequence.

The code is iterative; no conversion is going on in parallel. The HDF5 lib is built as threadsafe anyway. I rebuilt all the libraries from scratch and ran the ctests on the HDF libraries. Everything checked out. But the bug was still present.

On the 64 bit version of the exporter I run into none of this difficulty. 32 bit fails with both debug and release builds. All I get is the HDF5DotNet exception information: "Failed to find name of object in group # with index 0". The inputs all look fine. None of the HDF5-level error information is available.

Any thoughts?

Scott

________________________________________

This e-mail and any files transmitted with it may be proprietary and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error please notify the sender. Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of Exelis Inc. The recipient should check this e-mail and any attachments for the presence of viruses. Exelis Inc. accepts no liability for any damage caused by any virus transmitted by this e-mail.

Hey Gerd, I hope you're doing well.

I'm not directly calling H5Gget_objname_by_idx, but yeah that's what H5G::iterate is doing under the hood. H5G::iterate is using a MC++ int% which is safe_cast<size_t> to H5G::getObjectNameByIndex... and ultimately into H5Gget_objname_by_index. On my C# side, it's a ref to an int. The compiler isn't complaining or warning there. Presumably safe_cast<> is doing its job; it's not throwing an exception anyway.

Thanks,
Scott

···

-----Original Message-----
From: Hdf-forum [mailto:hdf-forum-bounces@lists.hdfgroup.org] On Behalf Of Gerd Heber
Sent: Thursday, May 21, 2015 8:55 AM
To: HDF Users Discussion List
Subject: Re: [Hdf-forum] .NET H5GgetObjectNameByIndexException

Scott, how are you? The (deprecated) H5Gget_objname_by_idx call has a size_t argument.
Could be a bug in the wrapper. (I haven't looked at the code.) Are you using an IntPtr?

G.

From: Hdf-forum [mailto:hdf-forum-bounces@lists.hdfgroup.org] On Behalf Of Mitchell, Scott - Exelis
Sent: Wednesday, May 20, 2015 2:35 PM
To: HDF Users Discussion List (hdf-forum@lists.hdfgroup.org)
Subject: [Hdf-forum] .NET H5GgetObjectNameByIndexException

I'm running into a strange bug that I can't wrap my head around.

I have a utility application/DLL that iterates through a folder of HDF5 files and extracts each dataset to csv. These files are generated with HDF5DotNet and HDF5 1.8.6 64 bit on a 64 bit machine. This build is well worn in 64 bit. Owing to a bunch of historic issues, the end user OSes are 32 bit. So the CSV exporter is 32 bit. When executing the 32 bit version of this exporter, I get a H5GgetObjectNameByIndexException. This happens sometime during the iteration, but it is inconsistent. It could start at any file in the sequence. It happens during my BuildDatasetList() which uses H5G.iterate to come up with a list of dataset names. Once it throws the exception, each successive file gets the same error, even though every HDF object is closed out properly. If I close the app and re-run, it starts ok and will randomly fail again somewhere in the file sequence.

The code is iterative; no conversion is going on in parallel. The HDF5 lib is built as threadsafe anyway. I rebuilt all the libraries from scratch and ran the ctests on the HDF libraries. Everything checked out. But the bug was still present.

On the 64 bit version of the exporter I run into none of this difficulty. 32 bit fails with both debug and release builds. All I get is the HDF5DotNet exception information: "Failed to find name of object in group # with index 0". The inputs all look fine. None of the HDF5-level error information is available.

Any thoughts?

Scott

________________________________________

This e-mail and any files transmitted with it may be proprietary and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error please notify the sender. Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of Exelis Inc. The recipient should check this e-mail and any attachments for the presence of viruses. Exelis Inc. accepts no liability for any damage caused by any virus transmitted by this e-mail.

_______________________________________________
Hdf-forum is for HDF software users discussion.
Hdf-forum@lists.hdfgroup.org
http://lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org
Twitter: https://twitter.com/hdf5