Re: [netcdfgroup] Netcdf 4.1.1, C++ interface, swapn4b, invalid write in libnetcdf.so.6.0.0

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




  • 2010 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the netcdfgroup archives: