Bring r20065 from trunk to 1.8 branch:
Bring changes from Coverity branch to trunk:
r19975:
Fixed potential mem leak at H5O_attr_open_by_name
r19980:
Fix coverity issue 792.
Free tmp_env_prefix in H5Lexternal.c line 365 if it is not NULL but its contents are 0 when it goes out of scope.
r20039:
Eliminate warnings about nested extern and implicit declarations of parallel_print and address Coverity defects 712-781 by #including h5tools_utils.h in h5diff_array.c, h5diff_attr.c, h5diff_dset.c and h5diff_util.c.
r20046:
Purpose: Address TOCTOU warnings in h5jam and h5unjam
Description: Coverity is afraid that the state of the input file could change
between the call to stat() and the call to open(). This is called a time-of-
check time-of-use (TOCTOU) vulnerability. Modified stat calls to fstat which
uses an open file pointer so it (hopefully) won't complain any more.
r20047:
Addressed coverity issues 135-137, 462-464. Local pointers that needed to be freed in case of error were moved out of a switch statement in src/H5Tnative.c, set to NULL, and checked before freeing.
Tested on:
Mac OS X/32 10.6.6 (amazon) w/debug & production
(h5committested on Coverity branch)
Bug 1707 is that H5Eset_auto causes a seg fault when an application uses -DH5_USE_16_API with
the 1.8 library to compile.
Tested on jam - backing out, simple.
has been removed. According to the official description of DESTDIR by Gnu at
http://www.gnu.org/prep/standards/html_node/DESTDIR.html, DESTDIR is
prepended to the normal and complete install path that it precedes for the
purpose of installing in a temporary directory which is useful for building
rpms and other packages. The '/' after ${DESTDIR} will be followed by another
'/' at the beginning of the normal install path. When DESTDIR is empty the
path then begins with '//', which is incorrect and causes problems at least for
Cygwin.
The change made in config/commence.am affects many Makefile.*s when bin/reconfigure
is run. EXAMPLEDIRs had to be corrected individually.
Also the scripts to run examples after they are installed have checks added to see
that the fortran and c++ directories are present before trying to run the scripts
in them.
Tested with h5committest on amani, heiwa and jam.
Tested with h5committest on amani, jam, and heiwa, and on linew.
-This line, and those below, will be ignored--
M hdf5_1_8/test/Makefile.in
A hdf5_1_8/m4
AM hdf5_1_8/m4/ltsugar.m4
AM hdf5_1_8/m4/libtool.m4
AM hdf5_1_8/m4/ltversion.m4
AM hdf5_1_8/m4/lt~obsolete.m4
AM hdf5_1_8/m4/ltoptions.m4
M hdf5_1_8/configure
M hdf5_1_8/Makefile.in
M hdf5_1_8/testpar/Makefile.in
M hdf5_1_8/configure.in
M hdf5_1_8/src/Makefile.in
M hdf5_1_8/tools/Makefile.in
M hdf5_1_8/tools/misc/Makefile.in
M hdf5_1_8/tools/h5dump/Makefile.in
M hdf5_1_8/tools/h5repack/Makefile.in
M hdf5_1_8/tools/h5jam/Makefile.in
M hdf5_1_8/tools/h5diff/Makefile.in
M hdf5_1_8/tools/lib/Makefile.in
M hdf5_1_8/tools/h5copy/Makefile.in
M hdf5_1_8/tools/h5import/Makefile.in
M hdf5_1_8/tools/h5stat/Makefile.in
M hdf5_1_8/tools/h5ls/Makefile.in
M hdf5_1_8/hl/test/Makefile.in
M hdf5_1_8/hl/tools/Makefile.in
M hdf5_1_8/hl/tools/gif2h5/Makefile.in
M hdf5_1_8/hl/Makefile.in
M hdf5_1_8/hl/src/Makefile.in
M hdf5_1_8/hl/c++/test/Makefile.in
M hdf5_1_8/hl/c++/Makefile.in
M hdf5_1_8/hl/c++/src/Makefile.in
M hdf5_1_8/hl/c++/examples/Makefile.in
M hdf5_1_8/hl/fortran/test/Makefile.in
M hdf5_1_8/hl/fortran/Makefile.in
M hdf5_1_8/hl/fortran/src/Makefile.in
M hdf5_1_8/hl/fortran/examples/Makefile.in
M hdf5_1_8/hl/examples/Makefile.in
M hdf5_1_8/config/commence.am
M hdf5_1_8/MANIFEST
M hdf5_1_8/c++/test/Makefile.in
M hdf5_1_8/c++/Makefile.in
M hdf5_1_8/c++/src/Makefile.in
M hdf5_1_8/c++/examples/Makefile.in
M hdf5_1_8/bin/ltmain.sh
M hdf5_1_8/bin/reconfigure
M hdf5_1_8/perform/Makefile.in
M hdf5_1_8/fortran/test/Makefile.in
M hdf5_1_8/fortran/testpar/Makefile.in
M hdf5_1_8/fortran/Makefile.in
M hdf5_1_8/fortran/src/Makefile.in
M hdf5_1_8/fortran/examples/Makefile.in
M hdf5_1_8/aclocal.m4
M hdf5_1_8/examples/Makefile.in
Corrected use/name of source folder aliases.
Duplicated FindMPI.cmake so that non-c++ compiler is found first (recommemded commands did not work).
Bring r19325 from trunk
Tested: local linux with mpich
Bring r19252 & 19253 from trunk to 1.8 branch:
Bring Coverity changes from branch to trunk:
r19161:
Fixed the part for matching the subset info with dataset
r19189:
BZ1646: h5dump does not check number of dimensions for subsetting parameters against the dataset
Changed subset_t structure from holding hsize_t pointers to holding new subset_d pointers, which hold the original hsize_t pointer + len. this len is then checked against dataset ndims in the handle_dataset function of h5dump.
Changed all references to use new data structure.
Added tests for each subset parameter.
r19190:
Added new h5dump ddl files
Tested on:
Mac OS X/32 10.6.4 (amazon) w/debug & production
(h5committested on Coverity branch)
Fixed file cleanup during make distclean / make check.
Description:
The h5jam Makefile and the h5importtestutil.sh script both included cleanup
steps that removed "*.txt" from the directory. This resulted in the new
CMake specific configuration file, CMakeLists.txt, getting blown away by
make distclean (for h5jam) and make check (for h5import).
I've removed the *.txt from the h5jam Makefile as the directory looks to be
getting cleaned appropriately without it, and I've modified the h5import
script h5importtestutil.sh to point to the specific .txt files to clean.
Tested:
jam
Improve configure's large-file support control.
Description:
Modified configure to now attempt to add defines necessary for
supporting largefiles on all systems, instead of solely on linux. This
is in response to user requests to enable largefile support on Solaris
by default, as well as to give extra control on AIX (instead of just
jamming the necessary flag into the config files).
The old --enable-linux-lfs flag is being deprecated in favor of the
--enable-largefile flag (enabled by default), which can be used on all
platforms. --disable-linux-lfs can still be used to disable largefile
support (on linux) when the --enable-largefile flag is not specified.
On systems where large files cannot be supported in this manner,
configure will report as such.
Tested:
h5committest
AIX (NCSA's blue_print machine)
duty, liberty, and linew.
Autotool Upgrade / Libtool Bug Fix
Description:
Updated autotools referenced in bin/reconfigure as follows:
Autoconf 2.64 --> Autoconf 2.65
Automake 1.11 --> Automake 1.11.1
Libtool 2.2.6a --> Libtool 2.2.6b-mcg
The referenced libtool version is a custom version of 2.2.6b. It
has been tweaked to fix a bug in libtool that occurs
when using PGI 10.0 compilers. A check incorrectly categorizes
the C++ compiler as version 1.0 instead of 10.0, and the link
line is subsequently set up incorrectly and fails to compile.
A patch has been made available and will be included in the next
release of libtool, but in the meantime I've applied the patch to a custom
installation as indicated above. This bin/reconfigure now references
the custom installation, and the resulting configure script will correctly
categorize the PGI 10.0 C++ compiler.
Ran bin/reconfigure to regenerate configure and makefiles.
Tested:
jam and amani with PGI 10.0 compilers.
h5committest
Bring r18212 from trunk to 1.8 branch:
Bring revisions from Coverity fixing branch to trunk:
r18184:
Fixed Coverity issue 373. Allocated memory freed in line 762 in case of error.
r18185:
Fixed Coverity issues 357 & 358. Added check for NULL pointer before use.
r18186:
Fix coverity item 65. Added code to h5unjam to correctly handle failures in
read() and write, and also to correctly handle writes that write less than
requested.
r18187:
Fix coverity items 115 and 116. Added code to H5Tenum.c to correctly close
opened datatypes in case of failure.
r18188:
Fixed Coverity issue 46. Check that dataset->shared is not null when freeing
memory after error.
r18190:
Fix coverity item 95. Added code to H5T_create_vlen to correctly close
allocated datatype in case of failure.
r18191:
Fixed Coverity error 59. Checked sfirst for -1 value before use in line 10533.
r18192:
Fix Coverity items 121 and 28
Added Asserts:
121: assert that all dimensions of count have values greater than zero.
28: assert curr_span pointer is not null before dereference.
Note: still need too add checks in hyperslab APIs that fail
when count values are zero, and appropriate tests.
r18194:
Fixed Coverity issues 61 & 62. Checked variable snpoints for value < 0 in line
218.
Tested on:
Mac OS X/32 10.6.2 (amazon) w/debug & production
(already daily tested on coverity branch)
The mixed use of RUNTEST (original) and RUNTESTS (new) caused
confusion. E.g., the timings in test/ was still using the old
$RUNTEST. It made more sense to use $RUNTEST which is used
by the dejagnu feature of automake. So, I changed all
$RUNTEST or $RUNTESTS to $RUNEXEC.
config/commence.am & config/conclude.am are the two files
that got changes. Also fixed an error in test/Makefile.am.
The rest are changed by bin/reconfigure.
Tested: h5committested.
Bring r17980 from trunk to 1.8 branch:
Bring Coverity changes into the trunk: (also other minor cleanups)
r17955:
Fix Coverity item 24. Add missing error condition to
H5AC_ext_config_2_int_config.
r17956:
Fix Coverity item 24. Improve error checking in H5A_compact_build_table_cb.
r17957:
Fix Coverity item 150. Fix warning in H5A_compact_build_table_cb.
r17958:
Fix Coverity item 117. Fix error handling in H5B_shared_new.
r17959:
Fix Coverity item 209. Added an assertion for leaf->shared in
H5B2_cache_leaf_dest.
r17960:
Fix Coverity item 208. Added an assertion for internal->shared in
H5B2_cache_internal_dest.
r17961:
Fix Coverity item 89. Reworked the code to avoid array overrun in
H5C__autoadjust__ageout__insert_new_marker.
r17962:
Fix for coverity Resource_leak 195,203,204,205.
r17963:
Fix Coverity item 44. Prevented potential NULL dereference in H5D_btree_debug.
r17964:
Fix Coverity issues #197, 198 & 199: memory not being released. (Also
clean up other resource leaks in nearby and/or similar code).
r17965:
Fix Coverity issue #151: release resources on error
r17966:
Fix Coverity issue #187: Remove leftover code remnant from prior bugfix
which was causing resource leak of open files.
r17967:
Fixed Coverity issues # 193 & 194. Removed unnecessary memory allocation and
added comparison of length of path parameter to the size of the destination
buffer in h5import.h/h5import.c.
r17968:
Fix Coverity item 144. Fixed memory leak on error in H5D_chunk_copy.
r17969:
Fix for coverity Resource_leak #196.
r17970:
Coverity 167-173:
Initialized pointer of buffers.
In error handling, closed types and free memory.
Tested on:
FreeBSD/64 6.3 (liberty) w/C++ & FORTRAN, in debug mode
(h5committested on trunk)
Merge from Trunk
Description:
Merging all of my CFLAGS-related changes from trunk to 1.8
This includes revision #s: 17616, 17625, 17627, 17639, and 17643.
Tested:
h5committest and some additional checks on our FreeBSD as well
as NCSA's machines.
Merge from trunk
Description:
Merged revisions 17228 and 17440 from trunk to 1.8
Specifically, this brings support of --enable-static-exec flag into 1.8
Tested:
Manually on jam, linew, smirom, liberty, plus h5committest.
Currently, there is no automatic regression test that exists due to
portability issues. Behavior is both different and undefined on certain
systems (and while 'nm' command seems to exist on all machines, behavior
is confirmed to be different on Mac, possibly others). Solution will be
to set up some sort of framework in daily tests to build statically,
remove shared paths, and verify executables can function.
Updating autotools
Description:
Bring revisions 17345 and 17357 from trunk to 1.8, specifically:
- Automake upgraded to 1.11
- Autoconf upgraded to 2.64
- bin/reconfigure script edited to use new versions (on jam), and
run to generate new configure script and Makefile.in's.
- configure.in script edited to add "_cv_" to all AC_CACHE_VAL strings
(in order to comply with new autoconf standard).
- bin/install-sh script replaced with new version as provided
by automake.
Tested:
- All issues on trunk were resolved, so only tested on jam and linew. Any
other outliers should be caught by daily tests.
Clean up various compiler warnings from IRIX64 build
Tested on:
Mac OS X/32 (amazon) debug & production
(yes, I know it's not an IRIX64 system :-)
Too minor to require h5committest
- Updated bin/reconfigure to use latest version of automake (1.10.2).
Regenerated Makefile.in's by running bin/reconfigure.
- Added libtool version numbers to c++, fortran, hl, hl c++, and hl fortran
libraries.
Tested:
jam, liberty, smirom
Bug Fix
Description:
Fixing BZ #1381. The --includedir=DIR configure option, which is used to
spceify installation location of C header files, did not work correctly as
the path was hard-coded into config/commence.am. I'm presuming this is
because an older version of automake didn't know where to put C header
files. In any case, removing this line now defaults the includedir to the
same directory that it is currently hard-coded to, and also fixes the
configure flag which allows for customization of this value.
Tested:
jam, liberty
have 2 expected outputs for 2 h5ls runs depending if run on a big or little endian machine. Configure.in was modified to export a variable carrying endianess information to testh5ls.sh. This script then compares the current run with 2 expected outputs, one for a big-endian machine (linew was used to generate the output), other for little endian (jam was used to generate the output)
the way h5ls prints types, it starts searching for NATIVE types first. One solution would be h5ls not to detect these native types, using for example the same print datatype function that h5dump does, that would make the output look the same on all platforms ("32-bit little-endian integer" would be printed instead). Drawback, this "native" information would not be available. Other solution is to have not one but 2 expected outputs and make the shell script detect the endianess and compare with one output or other
tested: jam, linew
Description: Libtool wasn't working on linew because the script was
not working with the Solaris Bourne shell. Libtool has built-
in detection to ensure that it uses an appropriate shell,
but our config/commence.am was hard coding this shell to be
/bin/sh. Removing this line allows the shell to be picked up
by configure, thus allowing libtool to use the correct shell
on linew (bash). This was initially added to correct for a problem
on an old machine (janus), so shoudn't be needed for machines
we currently support.
Tested: full make check install on kagiso and linew, compile only
on smirom, duty, and liberty.
Description:
1) configure now sets LD_LIBRARY_PATH before checking for presence of
SZIP encoder, so user does not need to set this. The path is then
saved and sent to Makefiles, and used when "make check-install" is
invoked, so user doesn't need to set this manually.
2) Upgraded libtool to version 2.2.6a
3) Rearranged tools build order as h5dump depends on existence of h5diff
and h5import. Since h5dump is a sister directory as opposed to a parent
of either, it doesn't know about the build rules of these tools, so
setting any sort of explicit dependency confuses automake as it won't
know how to build the tools. Instead, setting CONFIG = ordered forces
an in-order traversal of each tools subdirectory. (without it will also
traverse in order by default, but this should prevent gmake's -j option
from jumping ahead as well). 'make check install' should now be able to
be invoked after 'configure' without causing a dependency failure.
4) Removed H5_HAVE_LARGE_HSIZET macro from vms/src/h5pubconf.h, as this macro
has now been out of the code for some time. (vms pubconf needs to be
updated manually, which is why it was still hanging around).
Tested: kagiso, smirom, liberty
Note: h5diff looks to be causing failures in h5copy and h5dump tools tests,
though these were present before any of my changes. My changes only
affect build order and configuration setup, and shouldn't prevent
fixes for these failures coming in after this checkin. Other than these,
tests pass fine.
Description:
As part of our Windows cleanup, we try to remove windows-specific tweaks in the source code. There are many instances where Windows code is introduces via ifdef's. We re-evaluate whether they are still required, and found that many of them are not. Others we change to "feature"-specific code, rather than Windows-specific.
Tested:
VS2005 on WinXP
VS.NET on WinXP
h5committest (kagisopp, smirom, linew)
Description:
In library code, we try not to use system calls directly, but instead use the HD{function} macro instead. This way, we can map special versions of the call on particular systems. Previously, it was all done in H5private.h. However, in an effort to clean up platform-specific definitions, we move all of the Windows macros into a separate file, win32defs.h. This way, we can use the non-Posix versions that Visual Studio sends warnings about.
Some macros are set specifically in the platform-specific header files. Then, any macros left unset will be set by the "default" implementation in H5private.h.
This checkin also cleans up various source files to use the HD* macros when possible.
Tested:
VS2005 on WinXP
VS.NET on WinXP
h5committest (kagiso, linew, smirom)
Description:
The fortran Makefile.am used HDF_FORTRAN to indicate it is part of the
Fortran API source so that conclude.am will give fortran api prefix in the
test output. The symbox HDF_FORTRAN is also used in configure for a different
purpose (indicated --enable-fortran). They conflicted.
Similar problem for the symbol HDF_CXX.
Solution:
Changed all the involved Makefile.am to use "FORTRAN_API" instead. It is
a more appropriate name. Same for CXX_API.
Along the way, discovered that the Makefile.am of hl/fortran/test and
hl/cxx/test did not have those symbols at all. Added them in.
Platform tested:
Kagiso serial and h5committested (kagisopp, smirom, linew).
Improvement.
Description:
src/libhdf5.settings was the initial configure summary and is installed.
Then configure is changed to dump a summary of the configure settings to
the output and also append it to src/libhdf5.settings. That created
two different output formats and duplicated information. This is the
initial attempt to clean up this confusion and unify the output format.
It is decided to use the src/libhdf5.settings template as the unified means.
This requires more macros symbols be defined. The following symbols are
all related to generating the src/libhdf5.settings file.
AC_SUBST(EXTERNAL_FILTERS)
AC_SUBST(MPE) MPE=no
AC_SUBST(STATIC_EXEC) STATIC_EXEC=no
AC_SUBST(HDF_FORTRAN) HDF_FORTRAN=no
AC_SUBST(FC) HDF_FORTRAN=no
AC_SUBST(HDF_CXX) HDF_CXX=no
AC_SUBST(CXX) HDF_CXX=no
AC_SUBST(HDF5_HL) HDF5_HL=yes
AC_SUBST(GPFS) GPFS=no
AC_SUBST(LINUX_LFS) LINUX_LFS=no
AC_SUBST(INSTRUMENT) INSTRUMENT=no
AC_SUBST(CODESTACK) CODESTACK=no
AC_SUBST(HAVE_DMALLOC) HAVE_DMALLOC=no
AC_SUBST(DIRECT_VFD) DIRECT_VFD=no
AC_SUBST(THREADSAFE) THREADSAFE=no
AC_SUBST(STATIC_SHARED)
AC_SUBST(enable_shared)
AC_SUBST(enable_static)
AC_SUBST(UNAME_INFO) UNAME_INFO=`uname -a`
The src/libhdf5.settings.in has CONDITIONAL's added to it too. The
untrue conditions turned into a "#" and these lines are cleaned by the
post processing script.
Platform tested:
h5committest on kagiso, smirom and linew. (smirom had failures not due to
my changes.)
Description: Updated bin/reconfigure script to reflect the new versions of
libtool and automake in the /home1/packages/ directory.
Rearranged configure.in script. For some reason, when using
libtool 2.2, the libtool script doesn't generate until
later in the configuration process, so I had to move
a test that parsed through the libtool script to a point
after where it was actually being generated.
Ran libtoolize on the project, and ran bin/reconfigure to
regenerate configure and Makefile.in's throughout.
Tested: kagiso, smirom, linew, tg-login
Add work-around to allow reading files that were produced with a buggy
earlier version of the library, which could create objects with the wrong
object header message count. There is now a configure flag
"--enable-strict-format-checks" which triggers a failure on reading a file
with this sort of corruption (when enabled) and allows the object to be read
(when disabled). The default value for the "strict-format-checks" flag is
yes when the "debug" flag is enabled and no when the "debug" flag is disabled.
Note that if strict format checks are disabled (allowing objects with
this particular kind of corruption to be read) and the file is opened with
write access, the library will re-write the object header for the corrupt
object with the correct # of object header messages.
This closes bugzilla bug #1010.
Tested on:
FreeBSD/32 6.2 (duty) in debug mode
FreeBSD/64 6.2 (liberty) w/C++ & FORTRAN, in debug mode
Linux/32 2.6 (kagiso) w/PGI compilers, w/C++ & FORTRAN, w/threadsafe,
in debug mode
Linux/64-amd64 2.6 (smirom) w/default API=1.6.x, w/C++ & FORTRAN,
in production mode
Linux/64-ia64 2.6 (cobalt) w/Intel compilers, w/C++ & FORTRAN,
in production mode
Solaris/32 2.10 (linew) w/deprecated symbols disabled, w/C++ & FORTRAN,
w/szip filter, in production mode
Mac OS X/32 10.4.10 (amazon) in debug mode
Linux/64-ia64 2.4 (tg-login3) w/parallel, w/FORTRAN, in production mode
