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

[netCDF #VUC-284716]: NC_computeshapes Assertion

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: [netCDF #VUC-284716]: NC_computeshapes Assertion
  • Date: Wed, 16 Apr 2014 09:06:30 -0600
Clinton,

OK, the fix will be in the next netCDF C library release, version 4.3.2.  
Currently it's 
in the development version available from GitHub:

  https://github.com/unidata/netcdf-c

Thanks for reporting the issue!

--Russ

> On Wednesday, April 16, 2014 08:33:44 AM Unidata netCDF Support wrote:
> > Hi Clinton,
> >
> > > We intentionally have a corrupt file in a test suite to help test our
> > > error
> > > handling code.  See attached.
> > >
> > > However, we are updating to use NetCDF 4.3 and are getting this problem
> > > when we run ncdump on the file.
> > >
> > > ncdump: ../../libsrc/v1hpg.c:1160: NC_computeshapes: Assertion
> > > `ncp->begin_var <= ncp->begin_rec' failed.
> > >
> > > Older versions of NetCDF could handle this gracefully and return an error
> > > to our code.
> >
> > I'm curious what older version handled this any differently.  I just tested
> > older versions back to netCDF-3.6.1 (February 2006), and they all got the
> > same assertion violation.
> 
> Interesting... I was using NetCDF 4.1.1 before and didn't see an assertion
> there.  I'm not sure why.  Anyway...
> 
> >
> > Version 3.6.0 (December 2004) didn't get an assertion violation, but it also
> > didn't detect any error!   The ncdump from that version just emits zeros of
> > the appropriate type for all the values of variable(s) past the truncation
> > point.
> >
> > I've got a fix that replaces the assertions in libsrc/v1hpg.c with code to
> > return the error code NC_ENOTNC ("Not a netCDF file").  That passes all our
> > tests, and makes ncdump behave like this on your corrupted file:
> >
> >   $ ncdump ~/test/truncated.g
> >   ncdump: truncated.g: NetCDF: Unknown file format
> >
> > I think that should qualify as more graceful handling, but note that there
> > are surely other ways to corrupt a netCDF file that are not detected by
> > this change, and no possible way to detect a maliciously modified netCDF
> > file (e.g., if two variable names of the same length were swapped in the
> > header).  However, this modification would detect a lot of simple
> > corruptions, such as truncation.
> 
> That sounds reasonable and sufficient.  Thanks for your help!
> 
> Clint
> 
> 
> >
> > --Russ
> >
> > > Thanks for your attention.
> > >
> > > --
> > > Clinton Stimpson
> > > Elemental Technologies, Inc
> > > Computational Simulation Software, LLC
> > > www.csimsoft.com
> >
> > Russ Rew                                         UCAR Unidata Program
> > address@hidden                      http://www.unidata.ucar.edu
> >
> >
> >
> > Ticket Details
> > ===================
> > Ticket ID: VUC-284716
> > Department: Support netCDF
> > Priority: Normal
> > Status: Closed
> 
> --
> Clinton Stimpson
> Elemental Technologies, Inc
> Computational Simulation Software, LLC
> www.csimsoft.com
> 
> 
Russ Rew                                         UCAR Unidata Program
address@hidden                      http://www.unidata.ucar.edu



Ticket Details
===================
Ticket ID: VUC-284716
Department: Support netCDF
Priority: Normal
Status: Closed