Scot Breitenfeld
109e670e73
h5close_f reset its count of the objects created by h5open_f with
CALL h5fget_obj_count_f(INT(H5F_OBJ_ALL_F,HID_T), H5F_OBJ_ALL_F, &
H5OPEN_NUM_OBJ, error)
passing the H5F module variable H5OPEN_NUM_OBJ as the actual argument for
the INTENT(OUT) obj_count dummy, while h5fget_obj_count_f also reads
H5OPEN_NUM_OBJ by use association. F2018 15.5.2.13 prohibits referencing a
variable through use association once it has been redefined through a dummy
argument in the same call, so the result depended on how the compiler
implemented argument association. Where the actual argument was passed by
reference the subtraction collapsed to 0 - 0 and produced the intended zero;
where the compiler used copy-in/copy-out it evaluated 0 - H5OPEN_NUM_OBJ and
left the count negative.
A negative count then defeats the guard at the top of h5open_f, which returns
early when H5OPEN_NUM_OBJ is non-zero. h5open_f reported success without
calling h5init_types_c, leaving H5T_NATIVE_INTEGER and the other predefined
types holding identifiers that h5close_f had released.
h5close_f now assigns the count directly, which is what the comment there has
always described. h5fget_obj_count_f computes into a local variable so that no
caller can reintroduce the aliasing; note that this change alone would make
the old h5close_f call site produce the negative count on every compiler
rather than only on some, so the two belong together. H5OPEN_NUM_OBJ is also
given an initial value, since h5open_f tests it before anything assigns to it.
h5fget_obj_count_f subtracted every object created by h5open_f from a count of
a single object type, so with the interface open a query such as
CALL h5fget_obj_count_f(INT(H5F_OBJ_ALL_F,HID_T), H5F_OBJ_FILE_F, n, error)
returned a negative n and hdferr of 0. h5open_f now records what it leaves open
per object type, and a count is adjusted by the recorded value for the types
being counted, so the adjustment does not depend on which types the
initialization creates. The check for a negative count runs both on the value
returned by H5Fget_obj_count and after the adjustment.
h5fget_obj_ids_f applied no such adjustment, so it returned the identifiers
h5open_f opened alongside the application's own and disagreed with
h5fget_obj_count_f about the same query: with only a file and a group open,
H5F_OBJ_ALL_F counted 2 objects but listed 62. The C API reports 2 and 2. An
application walking the list found datatypes it never opened, and closing them
breaks the Fortran interface. h5fget_obj_ids_f now excludes those identifiers,
requesting enough from H5Fget_obj_ids that max_objs of the application's own
can still be returned when the two are interleaved.
The h5open/h5close test verified its object counts by calling
h5fget_obj_count_f after h5close_f, when h5open_f is the only call the Fortran
interface permits. Those checks move to after the interface is reopened, where
they additionally confirm that the predefined types are valid again, that the
preceding h5close_f released the previous h5open_f's types, and that
h5fget_obj_ids_f agrees with h5fget_obj_count_f.
The Fortran tests also aborted unrecoverable failures with STOP, which exits
with a success status whether the stop code is absent or is a string, so a run
that died part way through reported no failure to CTest. They now exit through
h5_exit_f(1). The STOPs that end a run normally, in fflush1 and in the async
test's skip path for a build without MPI_THREAD_MULTIPLE, are unchanged.
Fixes #6642
Fixes #6648
Reported and diagnosed by Dom Heinzeller.
The release_docs directory
This directory contains release artifacts only: changelogs, version history, release process documentation, and maintainer information.
User-facing guides (installation, build instructions, platform-specific docs)
have been moved to the docs/ directory.
Contents
CHANGELOG.md (formerly RELEASE.txt)
This is the changelog for the current version of the library.
For a MAJOR release (or in develop) this file lists all the changes since the
last major version. For a MINOR release (or in a maintenance branch), this file
lists all the changes since the last release in the maintenance branch.
Examples:
- The file for HDF5 1.14.0 includes all the changes since HDF5 1.12.0
- The file for HDF5 1.10.9 includes all the changes since HDF5 1.10.8
- The file in
developincludes all the changes since the last major release - The file in
hdf5_1_14includes all the changes since the last minor HDF5 1.14 release
HISTORY files
The HISTORY files contain the history of this branch of HDF5. They fall into
three categories.
HISTORY-[VERSION 1]-[VERSION 2].txt
These files are created when we release a new major version and include all
the changes that were made to the develop branch while creating a major release.
HISTORY-[VERSION].txt
This file contains the changes that were made to a maintenance branch since
it split off from develop. It will also be found in the develop branch
when experimental releases have been created.
Note that we make no effort to bring maintenance branch HISTORY files back to
develop. If you want to compare, say, 1.10.4 with 1.12.3, you'd have to get
the history files from those releases and compare them by hand.
RELEASE_PROCESS.md
Documentation for how releases are created and managed.
MAINTAINERS.md
Maintainer information for the project.
Creating new releases
MAJOR release
-
If there were experimental releases, merge the experimental
HISTORYfile and the currentCHANGELOG.mdby category to create a separate, unified file that ignores the experimental releases. Don't check this in yet or clobber any existingHISTORY/RELEASEfiles, but put it someplace handy for use in later steps. -
Create the new maintenance branch
In develop:
- Create the new
HISTORY-\[VERSION 1\]-\[VERSION 2\].txtfile- If there is an experimental
HISTORYfile, addCHANGELOG.mdto the beginning of it and use that - Otherwise, start with
CHANGELOG.md - Add the introduction boilerplate like in the other
HISTORYfiles (TOC, etc.)
- If there is an experimental
- Delete any experimental
HISTORYfile - Clear out
CHANGELOG.md
Note that we're KEEPING any experimental release history information in the
HISTORY-\[VERSION 1\]-\[VERSION 2\].txt file, so do NOT use the merged file in
the above steps!
In the new maintenance branch:
-
Create the new
HISTORY-\[VERSION\].txtfile- If there is an experimental
HISTORYfile use the combined file you created earlier - Otherwise, start with
CHANGELOG.md - Add the introduction boilerplate like in the other
HISTORYfiles (TOC, etc.)
- If there is an experimental
-
Delete any experimental
HISTORYfile -
Clear out
CHANGELOG.md -
Create the new release branch
In the new release branch:
- If there were experimental releases, use the combined file you created earlier as
CHANGELOG.md - Otherwise the
CHANGELOG.mdwill be used as-is
MINOR release
- Create the release branch
In the maintenance branch:
- Add the contents of
CHANGELOG.mdto the beginnnig ofHISTORY-\[VERSION\].txt - Clear out
CHANGELOG.md
EXPERIMENTAL release
- Add the contents of
CHANGELOG.mdto the beginnnig ofHISTORY-\[VERSION\].txt - Clear out
CHANGELOG.md