HDF5 version 1.14.3 released on 2023-10-27 ================================================================================ INTRODUCTION ============ This document describes the differences between this release and the previous HDF5 release. It contains information on the platforms tested and known problems in this release. For more details check the HISTORY*.txt files in the HDF5 source. Note that documentation in the links below will be updated at the time of each final release. Links to HDF5 documentation can be found on The HDF5 web page: https://portal.hdfgroup.org/display/HDF5/HDF5 The official HDF5 releases can be obtained from: https://www.hdfgroup.org/downloads/hdf5/ Changes from release to release and new features in the HDF5-1.14.x release series can be found at: https://portal.hdfgroup.org/display/HDF5/Release+Specific+Information If you have any questions or comments, please send them to the HDF Help Desk: help@hdfgroup.org CONTENTS ======== - New Features - Support for new platforms and languages - Bug Fixes since HDF5-1.14.2 - Platforms Tested - Known Problems - CMake vs. Autotools installations New Features ============ Configuration: ------------- - Improved support for Intel oneAPI * Separates the old 'classic' Intel compiler settings and warnings from the oneAPI settings * Uses `-check nouninit` in debug builds to avoid false positives when building H5_buildiface with `-check all` * Both Autotools and CMake - Added new options for CMake and Autotools to control the Doxygen warnings as errors setting. * HDF5_ENABLE_DOXY_WARNINGS: ON/OFF (Default: ON) * --enable-doxygen-errors: enable/disable (Default: enable) The default will fail to compile if the doxygen parsing generates warnings. The option can be disabled for certain versions of doxygen with parsing issues. i.e. 1.9.5, 1.9.8. Addresses GitHub issue #3398 - Added support for AOCC and classic Flang w/ the Autotools * Adds a config/clang-fflags options file to support Flang * Corrects missing "-Wl," from linker options in the libtool wrappers when using Flang, the MPI Fortran compiler wrappers, and building the shared library. This would often result in unrecognized options like -soname. * Enable -nomp w/ Flang to avoid linking to the OpenMPI library. CMake can build the parallel, shared library w/ Fortran using AOCC and Flang, so no changes were needed for that build system. Fixes GitHub issues #3439, #1588, #366, #280 - Converted the build of libaec and zlib to use FETCH_CONTENT with CMake. Using the CMake FetchContent module, the external filters can populate content at configure time via any method supported by the ExternalProject module. Whereas ExternalProject_Add() downloads at build time, the FetchContent module makes content available immediately, allowing the configure step to use the content in commands like add_subdirectory(), include() or file() operations. Removed HDF options for using FETCH_CONTENT explicitly: BUILD_SZIP_WITH_FETCHCONTENT:BOOL BUILD_ZLIB_WITH_FETCHCONTENT:BOOL - Thread-safety + static library disabled on Windows w/ CMake The thread-safety feature requires hooks in DllMain(), which is only present in the shared library. We previously just warned about this, but now any CMake configuration that tries to build thread-safety and the static library will fail. This cannot be overridden with ALLOW_UNSUPPORTED. Fixes GitHub issue #3613 - Autotools builds now build the szip filter by default when an appropriate library is found Since libaec is prevalent and BSD-licensed for both encoding and decoding, we build the szip filter by default now. Both autotools and CMake build systems will process the szip filter the same as the zlib filter is processed. - Removed CMake cross-compiling variables * HDF5_USE_PREGEN * HDF5_BATCH_H5DETECT These were used to work around H5detect and H5make_libsettings and are no longer required. - Running H5make_libsettings is no longer required for cross-compiling The functionality of H5make_libsettings is now handled via template files, so H5make_libsettings has been removed. - Running H5detect is no longer required for cross-compiling The functionality of H5detect is now exercised at library startup, so H5detect has been removed. Library: -------- - Added a simple cache to the read-only S3 (ros3) VFD The read-only S3 VFD now caches the first N bytes of a file stored in S3 to avoid a lot of small I/O operations when opening files. This cache is per-file and created when the file is opened. N is currently 16 MiB or the size of the file, whichever is smaller. Addresses GitHub issue #3381 - Added new API function H5Pget_actual_selection_io_mode() This function allows the user to determine if the library performed selection I/O, vector I/O, or scalar (legacy) I/O during the last HDF5 operation performed with the provided DXPL. Parallel Library: ----------------- - Added optimized support for the parallel compression feature when using the multi-dataset I/O API routines collectively Previously, calling H5Dwrite_multi/H5Dread_multi collectively in parallel with a list containing one or more filtered datasets would cause HDF5 to break out of the optimized multi-dataset I/O mode and instead perform I/O by looping over each dataset in the I/O request. The library has now been updated to perform I/O in a more optimized manner in this case by first performing I/O on all the filtered datasets at once and then performing I/O on all the unfiltered datasets at once. - Changed H5Pset_evict_on_close so that it can be called with a parallel build of HDF5 Previously, H5Pset_evict_on_close would always fail when called from a parallel build of HDF5, stating that the feature is not supported with parallel HDF5. This failure would occur even if a parallel build of HDF5 was used with a serial HDF5 application. H5Pset_evict_on_close can now be called regardless of the library build type and the library will instead fail during H5Fcreate/H5Fopen if the "evict on close" property has been set to true and the file is being opened for parallel access with more than 1 MPI process. Fortran Library: ---------------- - Fixed an uninitialized error return value for hdferr to return the error state of the h5aopen_by_idx_f API. - Added h5pget_vol_cap_flags_f and related Fortran VOL capability definitions. - Fortran async APIs H5A, H5D, H5ES, H5G, H5F, H5L and H5O were added. - Added Fortran APIs: h5pset_selection_io_f, h5pget_selection_io_f, h5pget_actual_selection_io_mode_f, h5pset_modify_write_buf_f, h5pget_modify_write_buf_f - Added Fortran APIs: h5get_free_list_sizes_f, h5dwrite_chunk_f, h5dread_chunk_f, h5fget_info_f, h5lvisit_f, h5lvisit_by_name_f, h5pget_no_selection_io_cause_f, h5pget_mpio_no_collective_cause_f, h5sselect_shape_same_f, h5sselect_intersect_block_f, h5pget_file_space_page_size_f, h5pset_file_space_page_size_f, h5pget_file_space_strategy_f, h5pset_file_space_strategy_f - Removed "-commons" linking option on Darwin, as COMMON and EQUIVALENCE are no longer used in the Fortran source. Fixes GitHub issue #3571 C++ Library: ------------ - Java Library: ------------- - Tools: ------ - High-Level APIs: ---------------- - Added Fortran HL API: h5doappend_f C Packet Table API: ------------------- - Internal header file: --------------------- - Documentation: -------------- - Support for new platforms, languages and compilers ================================================== - Bug Fixes since HDF5-1.14.2 release =================================== Library ------- - Fixed some issues with chunk index metadata not getting read collectively when collective metadata reads are enabled When looking up dataset chunks during I/O, the parallel library temporarily disables collective metadata reads since it's generally unlikely that the application will read the same chunks from all MPI ranks. Leaving collective metadata reads enabled during chunk lookups can lead to hangs or other bad behavior depending on the chunk indexing structure used for the dataset in question. However, due to the way that dataset chunk index metadata was previously loaded in a deferred manner, this could mean that the metadata for the main chunk index structure or its accompanying pieces of metadata (e.g., fixed array data blocks) could end up being read independently if these chunk lookup operations are the first chunk index-related operation that occurs on a dataset. This behavior is generally observed when opening a dataset for which the metadata isn't in the metadata cache yet and then immediately performing I/O on that dataset. This behavior is not generally observed when creating a dataset and then performing I/O on it, as the relevant metadata will usually be in the metadata cache as a side effect of creating the chunk index structures during dataset creation. This issue has been fixed by adding callbacks to the different chunk indexing structure classes that allow more explicit control over when chunk index metadata gets loaded. When collective metadata reads are enabled, the necessary index metadata will now get loaded collectively by all MPI ranks at the start of dataset I/O to ensure that the ranks don't unintentionally read this metadata independently further on. These changes fix collective loading of the main chunk index structure, as well as v2 B-tree root nodes, extensible array index blocks and fixed array data blocks. There are still pieces of metadata that cannot currently be loaded collectively, however, such as extensible array data blocks, data block pages and super blocks, as well as fixed array data block pages. These pieces of metadata are not necessarily read in by all MPI ranks since this depends on which chunks the ranks have selected in the dataset. Therefore, reading of these pieces of metadata remains an independent operation. - Fixed potential hangs in parallel library during collective I/O with independent metadata writes When performing collective parallel writes to a dataset where metadata writes are requested as (or left as the default setting of) independent, hangs could potentially occur during metadata cache sync points. This was due to incorrect management of the internal state tracking whether an I/O operation should be collective or not, causing the library to attempt collective writes of metadata when they were meant to be independent writes. During the metadata cache sync points, if the number of cache entries being flushed was a multiple of the number of MPI ranks in the MPI communicator used to access the HDF5 file, an equal amount of collective MPI I/O calls were made and the dataset write call would be successful. However, when the number of cache entries being flushed was NOT a multiple of the number of MPI ranks, the ranks with more entries than others would get stuck in an MPI_File_set_view call, while other ranks would get stuck in a post-write MPI_Barrier call. This issue has been fixed by correctly switching to independent I/O temporarily when writing metadata independently during collective dataset I/O. - Fixed a bug with the way the Subfiling VFD assigns I/O concentrators During a file open operation, the Subfiling VFD determines the topology of the application and uses that to select a subset of MPI ranks that I/O will be forwarded to, called I/O concentrators. The code for this had previously assumed that the parallel job launcher application (e.g., mpirun, srun, etc.) would distribute MPI ranks sequentially to a node's processors until all processors on that node have been assigned before going on to the next node. When the launcher application mapped MPI ranks to nodes in a different fashion, such as round-robin, this could cause the Subfiling VFD to incorrectly map MPI ranks as I/O concentrators, leading to missing subfiles. - Fixed a file space allocation bug in the parallel library for chunked datasets With the addition of support for incremental file space allocation for chunked datasets with filters applied to them that are created/accessed in parallel, a bug was introduced to the library's parallel file space allocation code. This could cause file space to not be allocated correctly for datasets without filters applied to them that are created with serial file access and later opened with parallel file access. In turn, this could cause parallel writes to those datasets to place incorrect data in the file. - Fixed an assertion failure in Parallel HDF5 when a file can't be created due to an invalid library version bounds setting An assertion failure could occur in H5MF_settle_raw_data_fsm when a file can't be created with Parallel HDF5 due to specifying the use of a paged, persistent file free space manager (H5Pset_file_space_strategy(..., H5F_FSPACE_STRATEGY_PAGE, 1, ...)) with an invalid library version bounds combination (H5Pset_libver_bounds(..., H5F_LIBVER_EARLIEST, H5F_LIBVER_V18)). This has now been fixed. - Fixed an assertion in a previous fix for CVE-2016-4332 An assert could fail when processing corrupt files that have invalid shared message flags (as in CVE-2016-4332). The assert statement in question has been replaced with pointer checks that don't raise errors. Since the function is in cleanup code, we do our best to close and free things, even when presented with partially initialized structs. Fixes CVE-2016-4332 and HDFFV-9950 (confirmed via the cve_hdf5 repo) - Fixed performance regression with some compound type conversions In-place type conversion was introduced for most use cases in 1.14.2. While being able to use the read buffer for type conversion potentially improves performance by performing the entire I/O at once, it also disables the optimized compound type conversion used when the destination is a subset of the source. Disabled in-place type conversion when using this optimized conversion and there is no benefit in terms of the I/O size. - Reading a H5std_string (std::string) via a C++ DataSet previously truncated the string at the first null byte as if reading a C string. Fixed length datasets are now read into H5std_string as a fixed length string of the appropriate size. Variable length datasets will still be truncated at the first null byte. Fixes Github issue #3034 - Fixed write buffer overflow in H5O__alloc_chunk The overflow was found by OSS-Fuzz https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=58658 Java Library ------------ - Configuration ------------- - Fixes the ordering of INCLUDES when building with CMake Include directories in the source or build tree should come before other directories to prioritize headers in the sources over installed ones. Fixes GitHub #1027 - The accum test now passes on macOS 12+ (Monterey) w/ CMake Due to changes in the way macOS handles LD_LIBRARY_PATH, the accum test started failing on macOS 12+ when building with CMake. CMake has been updated to set DYLD_LIBRARY_PATH on macOS and the test now passes. Fixes GitHub #2994, #2261, and #1289 - Changed the default settings used by CMake for the GZIP filter The default for the option HDF5_ENABLE_Z_LIB_SUPPORT was OFF. Now the default is ON. This was done to match the defaults used by the autotools configure.ac. In addition, the CMake message level for not finding a suitable filter library was changed from FATAL_ERROR (which would halt the build process) to WARNING (which will print a message to stderr). Associated files and documentation were changed to match. In addition, the default settings in the config/cmake/cacheinit.cmake file were changed to allow CMake to disable building the filters if the tgz file could not be found. The option to allow CMake to download the file from the original Github location requires setting the ZLIB_USE_LOCALCONTENT option to OFF for gzip. And setting the LIBAEC_USE_LOCALCONTENT option to OFF for libaec (szip). Fixes GitHub issue #2926 Tools ----- - Fixed an issue with unmatched MPI messages in ph5diff The "manager" MPI rank in ph5diff was unintentionally sending "program end" messages to its workers twice, leading to an error from MPICH similar to the following: Abort(810645519) on node 1 (rank 1 in comm 0): Fatal error in internal_Finalize: Other MPI error, error stack: internal_Finalize(50)...........: MPI_Finalize failed MPII_Finalize(394)..............: MPIR_Comm_delete_internal(1224).: Communicator (handle=44000000) being freed has 1 unmatched message(s) MPIR_Comm_release_always(1250)..: MPIR_finalize_builtin_comms(154): Performance ------------- - Fortran API ----------- - High-Level Library ------------------ - Fortran High-Level APIs ----------------------- - Documentation ------------- - F90 APIs -------- - C++ APIs -------- - Testing ------- - Disabled running of MPI Atomicity tests for OpenMPI major versions < 5 Support for MPI atomicity operations is not implemented for major versions of OpenMPI less than version 5. This would cause the MPI atomicity tests for parallel HDF5 to sporadically fail when run with OpenMPI. Testphdf5 now checks if OpenMPI is being used and will skip running the atomicity tests if the major version of OpenMPI is < 5. - Fixed Fortran 2003 test with gfortran-v13, optimization levels O2,O3 Fixes failing Fortran 2003 test with gfortran, optimization level O2,O3 with -fdefault-real-16. Fixes GH #2928. Platforms Tested =================== Linux 5.19.0-1023-aws GNU gcc, gfortran, g++ #24-Ubuntu SMP x86_64 GNU/Linux (Ubuntu 11.3.0-1ubuntu1~22.04) 11.3.0 Ubuntu 22.04 Ubuntu clang version 14.0.0-1ubuntu1 Intel(R) oneAPI DPC++/C++ Compiler 2023.1.0 ifort (IFORT) 2021.9.0 20230302 (cmake and autotools) Linux 5.16.14-200.fc35 GNU gcc (GCC) 11.2.1 20220127 (Red Hat 11.2.1-9) #1 SMP x86_64 GNU/Linux GNU Fortran (GCC) 11.2.1 20220127 (Red Hat 11.2.1-9) Fedora35 clang version 13.0.0 (Fedora 13.0.0-3.fc35) (cmake and autotools) Linux 5.14.21-cray_shasta_c cray-mpich/8.1.27 #1 SMP x86_64 GNU/Linux cce/15.0.0 (frontier) gcc/12.2.0 (cmake) Linux 5.11.0-34-generic GNU gcc (GCC) 9.4.0-1ubuntu1 #36-Ubuntu SMP x86_64 GNU/Linux GNU Fortran (GCC) 9.4.0-1ubuntu1 Ubuntu 20.04 Ubuntu clang version 10.0.0-4ubuntu1 Intel(R) oneAPI DPC++/C++ Compiler 2023.1.0 ifort (IFORT) 2021.9.0 20230302 (cmake and autotools) Linux 4.14.0-115.35.1.1chaos aue/openmpi/4.1.4-arm-22.1.0.12 #1 SMP aarch64 GNU/Linux Arm C/C++/Fortran Compiler version 22.1 (stria) (based on LLVM 13.0.1) (cmake) Linux 4.14.0-115.35.1.3chaos spectrum-mpi/rolling-release #1 SMP ppc64le GNU/Linux clang 12.0.1 (vortex) GCC 8.3.1 XL 2021.09.22 (cmake) Linux-4.14.0-115.21.2 spectrum-mpi/rolling-release #1 SMP ppc64le GNU/Linux clang 12.0.1, 14.0.5 (lassen) GCC 8.3.1 XL 16.1.1.2, 2021.09.22, 2022.08.05 (cmake) Linux-4.12.14-197.99-default cray-mpich/7.7.14 #1 SMP x86_64 GNU/Linux cce 12.0.3 (theta) GCC 11.2.0 llvm 9.0 Intel 19.1.2 Linux 3.10.0-1160.36.2.el7.ppc64 gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-39) #1 SMP ppc64be GNU/Linux g++ (GCC) 4.8.5 20150623 (Red Hat 4.8.5-39) Power8 (echidna) GNU Fortran (GCC) 4.8.5 20150623 (Red Hat 4.8.5-39) Linux 3.10.0-1160.24.1.el7 GNU C (gcc), Fortran (gfortran), C++ (g++) #1 SMP x86_64 GNU/Linux compilers: Centos7 Version 4.8.5 20150623 (Red Hat 4.8.5-4) (jelly/kituo/moohan) Version 4.9.3, Version 7.2.0, Version 8.3.0, Version 9.1.0, Version 10.2.0 Intel(R) C (icc), C++ (icpc), Fortran (icc) compilers: Version 17.0.0.098 Build 20160721 GNU C (gcc) and C++ (g++) 4.8.5 compilers with NAG Fortran Compiler Release 7.1(Hanzomon) Intel(R) C (icc) and C++ (icpc) 17.0.0.098 compilers with NAG Fortran Compiler Release 7.1(Hanzomon) MPICH 3.1.4 compiled with GCC 4.9.3 MPICH 3.3 compiled with GCC 7.2.0 OpenMPI 3.1.3 compiled with GCC 7.2.0 and 4.1.2 compiled with GCC 9.1.0 PGI C, Fortran, C++ for 64-bit target on x86_64; Versions 18.4.0 and 19.10-0 NVIDIA nvc, nvfortran and nvc++ version 22.5-0 (autotools and cmake) Linux-3.10.0-1160.0.0.1chaos openmpi-4.1.2 #1 SMP x86_64 GNU/Linux clang 6.0.0, 11.0.1 (quartz) GCC 7.3.0, 8.1.0 Intel 19.0.4, 2022.2, oneapi.2022.2 Linux-3.10.0-1160.90.1.1chaos openmpi/4.1 #1 SMP x86_64 GNU/Linux GCC 7.2.0 (skybridge) Intel/19.1 (cmake) Linux-3.10.0-1160.90.1.1chaos openmpi/4.1 #1 SMP x86_64 GNU/Linux GCC 7.2.0 (attaway) Intel/19.1 (cmake) Linux-3.10.0-1160.90.1.1chaos openmpi-intel/4.1 #1 SMP x86_64 GNU/Linux Intel/19.1.2, 21.3.0 and 22.2.0 (chama) (cmake) macOS Apple M1 11.6 Apple clang version 12.0.5 (clang-1205.0.22.11) Darwin 20.6.0 arm64 gfortran GNU Fortran (Homebrew GCC 11.2.0) 11.1.0 (macmini-m1) Intel icc/icpc/ifort version 2021.3.0 202106092021.3.0 20210609 macOS Big Sur 11.3.1 Apple clang version 12.0.5 (clang-1205.0.22.9) Darwin 20.4.0 x86_64 gfortran GNU Fortran (Homebrew GCC 10.2.0_3) 10.2.0 (bigsur-1) Intel icc/icpc/ifort version 2021.2.0 20210228 Mac OS X El Capitan 10.11.6 Apple clang version 7.3.0 from Xcode 7.3 64-bit gfortran GNU Fortran (GCC) 5.2.0 (osx1011test) Intel icc/icpc/ifort version 16.0.2 Linux 2.6.32-573.22.1.el6 GNU C (gcc), Fortran (gfortran), C++ (g++) #1 SMP x86_64 GNU/Linux compilers: Centos6 Version 4.4.7 20120313 (platypus) Version 4.9.3, 5.3.0, 6.2.0 MPICH 3.1.4 compiled with GCC 4.9.3 PGI C, Fortran, C++ for 64-bit target on x86_64; Version 19.10-0 Windows 10 x64 Visual Studio 2019 w/ clang 12.0.0 with MSVC-like command-line (C/C++ only - cmake) Visual Studio 2019 w/ Intel oneAPI 2023.2 C/C++ only - cmake) Visual Studio 2022 w/ clang 16.0.5 with MSVC-like command-line (C/C++ only - cmake) Visual Studio 2022 w/ Intel oneAPI 2023.2 (C/C++ only - cmake) Visual Studio 2019 w/ MSMPI 10.1 (C only - cmake) Known Problems ============== Building HDF5 Fortran on Windows with Intel oneAPI 2023.2 currently fails for this release with link errors. As a result, Windows binaries for this release will not include Fortran. The problem will be addressed in HDF5 1.14.4. IEEE standard arithmetic enables software to raise exceptions such as overflow, division by zero, and other illegal operations without interrupting or halting the program flow. The HDF5 C library intentionally performs these exceptions. Therefore, the "-ieee=full" nagfor switch is necessary when compiling a program to avoid stopping on an exception. CMake files do not behave correctly with paths containing spaces. Do not use spaces in paths because the required escaping for handling spaces results in very complex and fragile build files. ADB - 2019/05/07 At present, metadata cache images may not be generated by parallel applications. Parallel applications can read files with metadata cache images, but since this is a collective operation, a deadlock is possible if one or more processes do not participate. CPP ptable test fails on both VS2017 and VS2019 with Intel compiler, JIRA issue: HDFFV-10628. This test will pass with VS2015 with Intel compiler. The subsetting option in ph5diff currently will fail and should be avoided. The subsetting option works correctly in serial h5diff. Several tests currently fail on certain platforms: MPI_TEST-t_bigio fails with spectrum-mpi on ppc64le platforms. MPI_TEST-t_subfiling_vfd and MPI_TEST_EXAMPLES-ph5_subfiling fail with cray-mpich on theta and with XL compilers on ppc64le platforms. MPI_TEST_testphdf5_tldsc fails with cray-mpich 7.7 on cori and theta. Known problems in previous releases can be found in the HISTORY*.txt files in the HDF5 source. Please report any new problems found to help@hdfgroup.org. CMake vs. Autotools installations ================================= While both build systems produce similar results, there are differences. Each system produces the same set of folders on linux (only CMake works on standard Windows); bin, include, lib and share. Autotools places the COPYING and RELEASE.txt file in the root folder, CMake places them in the share folder. The bin folder contains the tools and the build scripts. Additionally, CMake creates dynamic versions of the tools with the suffix "-shared". Autotools installs one set of tools depending on the "--enable-shared" configuration option. build scripts ------------- Autotools: h5c++, h5cc, h5fc CMake: h5c++, h5cc, h5hlc++, h5hlcc The include folder holds the header files and the fortran mod files. CMake places the fortran mod files into separate shared and static subfolders, while Autotools places one set of mod files into the include folder. Because CMake produces a tools library, the header files for tools will appear in the include folder. The lib folder contains the library files, and CMake adds the pkgconfig subfolder with the hdf5*.pc files used by the bin/build scripts created by the CMake build. CMake separates the C interface code from the fortran code by creating C-stub libraries for each Fortran library. In addition, only CMake installs the tools library. The names of the szip libraries are different between the build systems. The share folder will have the most differences because CMake builds include a number of CMake specific files for support of CMake's find_package and support for the HDF5 Examples CMake project. The issues with the gif tool are: HDFFV-10592 CVE-2018-17433 HDFFV-10593 CVE-2018-17436 HDFFV-11048 CVE-2020-10809 These CVE issues have not yet been addressed and are avoided by not building the gif tool by default. Enable building the High-Level tools with these options: autotools: --enable-hlgiftools cmake: HDF5_BUILD_HL_GIF_TOOLS=ON