Update the gcc flags for version 4.3
Clean up warnings
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.5.3 (amazon) in debug mode
Linux/64-ia64 2.4 (tg-login3) w/parallel, w/FORTRAN, in production mode
Add a "HDcompile_assert" macro for assertions that can/should be checked
at compile time, as opposed to run time. (And used it for a couple of simple
cases, to begin)
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.5.3 (amazon) in debug mode
Linux/64-ia64 2.4 (tg-login3) w/parallel, w/FORTRAN, in production mode
Avoid leaking memory when copying the internal "shared" struct for
a named datatype when it's already been opened earlier.
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.5.3 (amazon) in debug mode
Linux/64-ia64 2.4 (tg-login3) w/parallel, w/FORTRAN, in production mode
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:
On Windows, the pthread_self function cannot be used to print the returned thread ID for debugging. Instead, we need a separate function, GetCurrentThreadId. To eliminate some Windows ifdef's in the code, we create two new function macros which can be used by all platforms. It is conditionally defined in H5win32defs.h, and globally in H5private.h.
Tested:
VS2005 w/ pthreads on WinXP
kagiso w/ pthreads
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)
Correct the definition of the 'nbytes' variable in the in-memory version
of the B-tree key for chunks from 'size_t' to 'uint32_t', to match the
definitions everywhere else.
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/64 2.10 (linew) in debug mode
Solaris/32 2.10 (linew) w/deprecated symbols disabled, w/C++ & FORTRAN,
w/szip filter, in production mode
Mac OS X/32 10.5.3 (amazon) in debug mode
Linux/64-ia64 2.4 (tg-login3) w/parallel, w/FORTRAN, in production mode
Finish omnibus chunked dataset I/O refactoring, to separate general
actions on chunked datasets from actions that are specific to using the v1
B-tree index.
Cleaned up a few bugs and added some additional tests also.
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.5.2 (amazon) in debug mode
Linux/64-ia64 2.4 (tg-login3) w/parallel, w/FORTRAN, in production mode
Description:
On Linux-like systems, we can get the ID of the current thread through a pthread_self. However on Windows, the return cannot be cast as a threadID, so we simply couldn't get the ID. Previously we simply gave up and printed a message that we couldn't get an ID. Instead, though, we can use the Windows-specific call to GetCurrentThreadId(), which achieves the same goal. This way we can provide better debug output with threadsafe features.
Tested:
VS2005 on WinXP
VS.NET on WinXP
(other platforms not tested because change is within _WIN32 ifdef)
Description:
Previously, there was Windows-dependent code inside H5detect.c, because not all projects could access the gethostname() function. However, we standardize our project-files to link with WS2_32.lib, so now this function is available. Thus, the Windows-specific code has been removed from H5detect.c.
Tested:
VS2005 on WinXP
VS.NET on WinXP
no need to test other platforms, Windows-specific source change
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 only. It is a trivia change.
Detect chunks that are >4GB before dataset gets created and return error
to application.
Tweak lots of internal variables that hold the chunk size/dimensions to
use an 'uint32_t', instead of a 'size_t', so that the integer size is constant.
Correct a number of our tests which were creating datasets with chunks
that were >4GB and add some specific tests for >4GB chunk size detection.
Minor whitespace & other code cleanups.
Tested on:
Mac OS X/32 10.5.2 (amazon)
Forthcoming testing on other platforms...
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.
Description:
In the new tests merged from the fortran_1_8 branch, there is a test that fetches a dataset name in a small buffer. The call to H5G_get_name_by_addr wrote an extra byte off the end of the buffer. A simple and sufficient fix is to decrease the buffer size passed to strncmp by 1. This bug was only caught by Visual Studio 2005 with extra debug checks on.
Tested:
VS2005 on WinXP
kagiso
Description: Applying update to autotools that was applied to 1.8 a couple
of weeks ago to the trunk.
Updated bin/reconfigure script to reflect the new versions of
libtool and automake in the /home1/packages/ directory.
Rearranged configure.in script. When using libtool 2.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 (h5committest)
Omnibus raw data I/O revisions, with wide-ranging changes and
refactoring, in order to prepare for implementing "fast append" feature.
These changes remove the majority of the code duplication for raw data
I/O which has crept in over the last ten years and introduces a more object-
oriented design for operating on different types of dataset storage.
Chunked storage no longer has it's own I/O routines, it is now handled
as either contiguous (if chunk is not pulled into the cache) or compact (if the
chunk is cached in memory).
No bug or feature changes, at least intentionally... :-)
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.5.2 (amazon) in debug mode
Linux/64-ia64 2.4 (tg-login3) w/parallel, w/FORTRAN, in production mode
remove HDputenv() from external_link_env() test
(will add script later to set HDF5_EXT_PREFIX for running the test)
modify and add more comments
2. src/H5private.h: remove #define for HDputenv()
Tested on kagiso, linew and smirom.
H5_DLL herr_t H5_build_extpath(const char *, char **/*out*/);
makes this stupid warning in windows that gets repeated in every source file
c:\_pvn\hdf5\src\h5private.h(958) : warning C4138: '*/' found outside of comment
changed signature to
H5_DLL herr_t H5_build_extpath(const char *, char ** /*out*/ );
compiler is happy now
tested: windows, linux
Bring r14737 back from the 1.8 branch: Fix bug which would
incorrectly encode the member offsets for compound datatypes whose size was
between 256 & 511 bytes, when the "use the latest format" feature was enabled.
Tested on:
Mac OS X/32 10.5.2 (amazon) w/debug
FreeBSD/32 6.2 (duty) w/production
Minor bug fix to H5Aget_num_attrs() to return error when an invalid
location ID is passed in.
Tested on:
Mac OS X/32 (amazon)
Too minor to require h5committest
Add 2 more parameters to H5HF_man_iblock_size() (parent iblock and parent entry)
for passing onto H5HF_iblock_man_iblock_protect().
This bug was there before but was revealed now by exercising the recursive part of the code from the new
"h5stat_newgrat.h5".
Tested on kagiso, smirom and linew with --disable-production.
2. H5HFstat.c: Since H5HF_space_size() zeroed out fs_size, add "meta_size" to store
free-space size before adding to "heap_size".
3. h5stat_gentest.c: increase # of groups to get "h5stat_newgrat.h5" that contains
indirect block entries in fractal heap.
This is for testing the recursive part of the code in H5HF_man_iblock_size().
4. h5stat_newgrat.h5: the new .h5 file generated by h5stat_gentest.c.
5. h5stat_newgrat.ddl: expected output from new "h5stat_newgrat.h5".
Description: config/lt_vers.am was updated as follows due to changes in API
since last version update:
LT_VERS_INTERFACE = 5
LT_VERS_REVISION = 0
LT_VERS_AGE = 0
Tested: kagiso
As best I can tell, H5C_make_space_in_cache() was accessing memory
that had been deallocated -- however the bug was easy to mask, and
jumped around even in different runs of the same executable. While
I was never able to generate a definitive test case that exposed
exactly where the core dump occured, I was able to generate print
statement traces which made it clear that I was accessing freed
memory.
In any case, reworking the code to avoid the reference to freed
cache entries seems to have fixed the problem.
Tested serial production on Phoenix, and commit tested. Also,
partial tests Linew.
detect and handle the case in which the skip list or LRU is modified
out from under a scan of same by the flush callback of the entry under
consideration.
Test serial debug, serial production, and parallel debug on phoenix,
and commit tested.
callback functions modifies the skip list or LRU out from under a partial
or complete flush of the cache. This is a test for a situation that
should not occur, but we test anyway.
Also added code to skip longer tests in cache_api in express tests.
Tested serial and parallel on phoenix (debian --x86-32), and commit test.
Elena commit tested as well, and ran a manual test under MacOS X.
large entry, or to a large increases in the size of an existing entry.
This required some additions to the cache configuration structure, and
thus will require changes in the metadata cache documentation.
The basic idea is to monitor the size of entries as they are loaded,
inserted, or increased in size. If the size of the entry (or increase)
exceeds some user selected fraction of the size of the cache, increase
the size of the cache.
Note that this fix was designed quickly -- while it deals with the
use case that exposed the problem, we may have to revisit the issue
later.
Tested serial and parallel on Phoenix, and h5committest.
