Re: 20020107: ncgen issue

>To: address@hidden
>From: Roy Britten <address@hidden>
>Subject: ncgen issue
>Organization: UCAR/Unidata
>Keywords: 200201072127.g07LRhN00541

Hi Roy,

> I've encountered a problem using ncgen that I would appreciate your
> advice on. We're currently looking at using netCDF to temporarily store
> large sets of character string data (not my decision ...); ncgen is
> failing in the following manner:
> 
> ncgen:
> ncgen: -: netcdf library version 3.4 of Oct 28 1999 20:27:24 $
> ncdump:
> netcdf library version 3.4 of Oct 28 1999 20:27:24 $
> platform:
> IRIX64 6.5
> 
> I use here a simple example where we assume that we wish to store
> character strings of max length 20 characters, in "clusters" of 4
> strings:
> 
> netcdf problem {
> dimensions:
>       strlen = 20;
>       numfields = 4;
>       numrecords = unlimited;
> variables:
>       char    fieldnames      (numrecords, numfields, strlen);
> data:
>  fieldnames =
> 
>       "a",
>       "b",
>       "c",
>       "d",
> 
>       "e",
>       "f",
>       "g",
>       "h";
> }
> 
> 
> ncgen -b will run on this file, but when the output is run through
> ncdump the following output results:
> 
> 
> netcdf problem {
> dimensions:
>         strlen = 20 ;
>         numfields = 4 ;
>         numrecords = UNLIMITED ; // (2 currently)
> variables:
>         char fieldnames(numrecords, numfields, strlen) ;
> data:
> 
>  fieldnames =
>   "a",
>   "b",
>   "c",
>   "d",
>   "e",
>   "f",
>   "g\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000c",
>   "h" ;
> }
> 
> Furthermore, as soon as another character string is added to the data,
> taking the value of numrecords > 2, we dump core:
> 
> 
> $ ncgen -b problem.cdl
> Bus error (core dumped)
> 
> 
> However, if numrecords is changed from unlimited to any appropriate
> value, ncgen runs without crashing, and ncdump reports the expected
> result, for all data sizes that I've attempted (up to ~10kB).
> 
> Is this a known issue?

I have reproduced the problem on our IRIX64 platform using netCDF
version 3.5.0, but it doesn't occur with either netCDF 3.4 or netCDF
3.5.0 using either the 32-bit or 64-bit compilation environments on a
Solaris 8 platform.  So although it appears to be platform-specific, I
don't know yet where the bug is.  

Thanks for reporting this bug, which hasn't been reported before, as
far as I know.  I'll let you know when I get a workaround or fix for
it, but it may be next week, as I'm involved in a workshop for the
rest of this week.

--Russ