[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[netCDF #TLH-274520]: Probable bug in netCDF compression



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-4.2.1.1-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 4.2.1.1 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-4.2.1.1 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