Thomas Taylor wrote:
Further to add: this error as described below can be reproduced with netcdf
4.1.1, 4.0.1 and 3.6.2.
> (2) With both 4.0.1 and 4.1.1 reproducible, but seemingly random, crashes
> occur when reading AMBER files. Running a small test program via valgrind
> gives the following:
>
> [ OPEN FILE A
> [ READ VALUES "coordinates" from 0,0,0 to 9,0,2
> [ OPEN FILE B
> [ READ VALUES "coordinates" from 0,0,0 to 9,0,2
>
> [ FIRST ERROR BY valgrind (AFAIK ALWAYS after having read data from each
> file once, so probably occuring when trying to open file A for the second
> time...
> Invalid write of size 1
> at 0x7D1AB65: swapn4b (in /usr/lib/libnetcdf.so.6.0.0)
> by 0x7D1E015: ncx_getn_float_float (in /usr/lib/libnetcdf.so.6.0.0)
> by 0x7D2896F: getNCv_float (in /usr/lib/libnetcdf.so.6.0.0)
> by 0x7D2E5E1: nc3_get_vara_float (in /usr/lib/libnetcdf.so.6.0.0)
> by 0x7D09589: nc_get_vara_float (in /usr/lib/libnetcdf.so.6.0.0)
> by 0x4E374B6: NcVar::get(float*, long const*) const (in
> /usr/lib/libnetcdf_c++.so.5.0.0)
> by 0x4267AD:
> gepetto::system::amber::netcdf::Parser::readTAX(std::string
> const&, long*, long*, float*) (parser.cpp:334)
> by 0x406EB5: calc(std::vector<std::string, std::allocator<std::string>
> >
> const&) (correlation.cpp:82)
> by 0x407FC9: main (correlation.cpp:179)
> Address 0x955b728 is 0 bytes after a block of size 40 alloc'd
> at 0x4C25509: operator new[](unsigned long) (in
> /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> by 0x406BBE: calc(std::vector<std::string, std::allocator<std::string>
> >
> const&) (correlation.cpp:49)
> by 0x407FC9: main (correlation.cpp:179)
>
> [ READ LOTS OF MORE VALUES, always cycling through all files
> [ SECOND ERROR after arbitrary number of reads/file switches, presumably
> again when trying to open one of the files...
> valgrind: m_mallocfree.c:248 (get_bszB_as_is): Assertion 'bszB_lo ==
> bszB_hi' failed.
> valgrind: Heap block lo/hi size mismatch: lo = 112, hi =
> 4717696923473706361.
> This is probably caused by your program erroneously writing past the
> end of a heap block and corrupting heap metadata. If you fix any
> invalid writes reported by Memcheck, this assertion failure will
> probably go away. Please try that before reporting this as a bug.
>
> at 0x3802B8B9: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
> by 0x3802BA88: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
> by 0x380372D8: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
> by 0x38001B19: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
> by 0x38064842: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
> by 0x38073F84: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
>
> sched status:
> running_tid=1
>
> Thread 1: status = VgTs_Runnable
> at 0x4C2497E: operator delete[](void*) (in
> /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> by 0x4E362ED: NcVar::~NcVar() (in /usr/lib/libnetcdf_c++.so.5.0.0)
> by 0x4E36318: NcVar::~NcVar() (in /usr/lib/libnetcdf_c++.so.5.0.0)
> by 0x4E3A312: NcFile::close() (in /usr/lib/libnetcdf_c++.so.5.0.0)
> by 0x42D1A6: gepetto::system::amber::netcdf::Parser::close()
> (parser.h:82)
> by 0x42CDF0: gepetto::system::amber::netcdf::Parser::open(std::string
> const&) (parser.h:70)
> by 0x406E74: calc(std::vector<std::string, std::allocator<std::string>
> >
> const&) (correlation.cpp:80)
> by 0x407FC9: main (correlation.cpp:179)
>
>
> Please note that I have tried this scheme with different numbers of files,
> and with both 4.0.1 and 4.1.1, always to the same effect.
> Please also note that every call to FilePointer = new NcFile(args), is
> preceded by OldFilePointer->close()
>
> Feel free to offer any advice and suggestions, including how to turn this
> into a proper bug report.
>
Thank you,
Thomas Taylor
