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

[netCDF #CKA-677320]: NF_CREATE crash



> Hi Ansley,
> 
> > Using the source from this URL,
> >
> > ftp://ftp.unidata.ucar.edu/pub/netcdf/netcdf-test.tar.gz
> >
> > I'm seeing a problem with NF_CREATE. The call is this, with
> > cdftype=NF_CLASSIC_MODEL and with clobber_mode set to either
> > NF_NOCLOBBER or NF_CLOBBER. The call is made by program ferret_c, and
> > its result is below:
> >
> > cdfstat = NF_CREATE(cdfname, OR(clobber_mode,cdftype), cdfid)
> >
> > ferret_c: nc4file.c:395: NC4_create: Assertion `0' failed.
> > Abort
> >
> >
> > Setting cdftype to NF_NETCDF4 and making the same call lets me
> > successfully create and write to the file.
> 
> I can't reproduce this problem using gfortran.  What happens when you
> use the function IOR() instead of OR() ?, as in:
> 

Howdy Russ and Ansley!

I can reproduce this in C.

The problem is that Ansley is using NC_CLASSIC_MODEL, but not using netCDF-4! 
It didn't occur to us that anyone would do that. ;-(

So this caused two problems. The dispatch layer thought that it should use the 
netCDF-4 dispatch table (because if you are not using netCDF-4, then why use 
CLASSIC_MODEL?), and then the netCDF-4 version of the create function got 
called, and asserted itself because it believed that it should only be called 
with NC_NETCDF4 set in the mode flag.

Here we see a lesson in why asserts can be much worse than simply returning an 
error code. By returning the generic NC_EINVAL the nc_create function would hit 
the nail on the head! The input parameters are invalid.

But, of course, we are handling things is a very sloppy manner and that can be 
fixed. I have changed the code so that we do not assume netCDF-4 dispatch table 
when CLASSIC_MODEL is used. In fact, we ignore CLASSIC_MODEL if a classic 
netCDF file is being opened. This is now tested in libsrc4/tst_files.c. So your 
code should work as is, even though there is no reason in the world why you 
should set NC_CLASSIC_MODEL when creating a classic format file (because what 
else can it be?).

But that's OK. We want our users to be happy, and if setting this flag brings 
even a tiny bit of happiness to you, Ansley, I am delighted. ;-)

I have checked in this code and regenerated the daily snapshot with it. This 
also includes the fix that Dennis sent you as a branch build a few days ago 
(the vars fix).

ftp://ftp.unidata.ucar.edu/pub/netcdf/snapshot/netcdf-4-daily.tar.gz

Thanks for finding this Ansley!

Ed

Ticket Details
===================
Ticket ID: CKA-677320
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.