Lynton, > The line that has the uninitialized value, line 1442 in routine deflate.c > is part of the ZLIb library. I am using version 1.27 and have compiled > with debug using the following line: > CFLAGS="-g" ./configure --prefix=/work/lappel/local/zlib/1.2.7 --shared > This overules the usual -O3 build option. > > The example I provided uses compression level 1. If I increase the > compression > level (nc_def_var_deflate), the error does not occur for compression >=4. > > The error also doesn't occur with ZLIB built with -O3, which I presume > you are > using. Assuming we could reproduce the problem after rebuilding zlib, rebuilding HDF5 to use that zlib, and rebuilding netCDF-188.8.131.52-patched to use that HDF5, I'm not sure we could do anything useful with the resulting valgrind problem. It sounds like something to report to the zlib developer, Mark Adler. However, I see this zlib FAQ and answer about the valgrind error: http://www.zlib.net/zlib_faq.html#faq36 that makes me skeptical that zlib is the source of the problem. --Russ > On 04/16/2013 03:19 AM, Unidata netCDF Support wrote: > > Hi Lynton, > > > >> I have found a problem associated with compression of variables. > >> The example I am attaching is apparent from running valgrind as > >> it reports the condition: > >> > >> "Conditional jump or move depends on uninitialised value(s)" > >> in routine fill_window (deflate.c:1442) > >> However, I suspect that the problem may be the cause of a segment core > >> dump in my full programme when using compiler optimisatiion. > >> > >> I attach a tar-zipped file of the test example. > >> This includes the netCDF output file and the screen output > >> from running valgrind > >> valgrind ./test>valgrind.out > >> > >> > >> I am using hdf5 version 1.8.10-patch1 > >> and netCDF version 184.108.40.206 with the patch described by JIRA ticket NCF=217 > >> // https://bugtracking.unidata.ucar.edu/browse/NCF-217 : > >> // for (dim = grp->dim; dim&& dim->next; dim = dim->next) > >> // if (strcmp(dim->name, var->name)&& !dim->dirty) > >> for (dim = grp->dim; dim ; dim = dim->next) > >> if (!strcmp(dim->name, var->name)&& !dim->dirty) > > Sorry, but I can't seem to duplicate the problem. Using the same version of > > HDF5 (1.8.10-patch1) and the same patch applied to netCDF-220.127.116.11 built > > using > > that version of HDF5, the test works fine and valgrind shows no errors: > > > > C_test2$ make test > > gcc -g -I/machine/russ/installs/nc4211-patched/include > > -I/share/ed/local/spike/include -c -o test.o test.c > > gcc -g -I/machine/russ/installs/nc4211-patched/include > > -I/share/ed/local/spike/include -c -o ncCheck.o ncCheck.c > > gcc test.o ncCheck.o -L/machine/russ/installs/nc4211-patched/lib > > -lnetcdf -Wl,-rpath -Wl,/machine/russ/installs/nc4211-patched/lib -o test > > C_test2$ ./test > > C_test2$ valgrind ./test > > ==2964== Memcheck, a memory error detector > > ==2964== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. > > ==2964== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info > > ==2964== Command: ./test > > ==2964== > > ==2964== > > ==2964== HEAP SUMMARY: > > ==2964== in use at exit: 541,960 bytes in 40 blocks > > ==2964== total heap usage: 2,969 allocs, 2,929 frees, 2,012,562 bytes > > allocated > > ==2964== > > ==2964== LEAK SUMMARY: > > ==2964== definitely lost: 0 bytes in 0 blocks > > ==2964== indirectly lost: 0 bytes in 0 blocks > > ==2964== possibly lost: 0 bytes in 0 blocks > > ==2964== still reachable: 541,960 bytes in 40 blocks > > ==2964== suppressed: 0 bytes in 0 blocks > > ==2964== Rerun with --leak-check=full to see details of leaked memory > > ==2964== > > ==2964== For counts of detected and suppressed errors, rerun with: -v > > ==2964== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 32149 from 5) > > > > C_test2$ valgrind --version > > valgrind-3.8.1 > > C_test2$ gcc --version > > gcc (GCC) 4.5.1 20100924 (Red Hat 4.5.1-4) > > > > --Russ > > > > > > Russ Rew UCAR Unidata Program > > address@hidden http://www.unidata.ucar.edu > > > > > > > > Ticket Details > > =================== > > Ticket ID: TLH-274520 > > Department: Support netCDF > > Priority: Normal > > Status: Closed > > > > Russ Rew UCAR Unidata Program address@hidden http://www.unidata.ucar.edu Ticket Details =================== Ticket ID: TLH-274520 Department: Support netCDF Priority: Normal Status: Closed
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.