segmentation fault: gasdf.c:3237, index out of bound

[Jennifer Adams]

Hi, Ryo --
I took your ncdump output and used it (and ncgen) to generate a test
netcdf file:

netcdf test {
dimensions:
         lon = 1 ;
         lat = 1 ;
        dep = 30;
         time = 1 ;
variables:
         float lon(lon) ;
                 lon:units = "degrees_east" ;
         float lat(lat) ;
                 lat:units = "degrees_north" ;
        float dep(dep) ;
                dep:units = "meters" ;
                dep:axis = "Z" ;
                dep:positive = "down" ;
         int time(time) ;
                 time:units = "days" ;
        float var(time, dep, lat, lon);
                var:long_name="test variable";
data:
  lon = 1;
  lat = 1;
  time = 1;
  dep = 5, 15, 25, 35, 45, 55, 65, 75, 85, 95, 105, 115.9789, 129.7985,
     148.0428, 171.8625, 201.8625, 238.0428, 279.7985, 325.9789, 375,
425,
     491.1513, 604.1757, 790.2066, 1068.231, 1448.231, 1930.207,
2504.176,
     3151.151, 3845 ;
  var = 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17,
18, 19,
     20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30;
}

I can open this netcdf file with GrADS 1.9 and 2.0 and display the
test variable without any seg faults. You will have to provide all
the ncdump -c output from your file -- maybe this will help me to
reproduce the error.

As for the positive:down attribute, GrADS was designed with the
atmosphere in mind, so z=1 is the bottom (close to the surface) and
z=zmax is at the top. When your z axis is depth, this orientation is
maintained, so that the bottom (deepest) level is z=1 and the top
(shallowest) layer is z=30. That is somewhat opposite to the way
oceanographers think of the Z (depth) axis, where z=1 is usually at
or just below the surface.
--Jennifer


On Feb 18, 2008, at 4:40 AM, Ryo Furue wrote:

> Dear GrADS maintainers,
>
> I'd like to report a bug.
>
> For a netCDF file, line 3237
>
>   3237   fgrid[ginx] = fakefgrid[indx] ;
>
> of gasdf.c causes a segmentation fault.  It turns out that ginx
> gets a negative value, which in turn is caused by
>
>   3230   ginx = (gtinx - gridptr->dimmin[GTINDEX]) * zyxsize +
>   3231          (gzinx - gridptr->dimmin[GZINDEX]) * yxsize +
>   3232          (gyinx - gridptr->dimmin[GYINDEX]) * gxsize +
>   3233          (gxinx - gridptr->dimmin[GXINDEX]) ;
>
> where
>
>    gtinx == 1
>    gridptr->dimmin[GTINDEX] == 1
>    gzinx == 1
>    gridptr->dimmin[GZINDEX] == 30
>    gyinx == 1
>    gridptr->dimmin[GYINDEX] == 1
>    gxinx == 1
>    gridptr->dimmin[GXINDEX] == 1
>
> Another, probably related oddity is that GrADS seems to be confused
> about a vertical axis with an attribute 'positive = "down" '.
> Index 1 of my depth coordinate corresponds the shallowest level
> and index 30 corresponds to the deepest.  But, in GrADS, z = 1
> corresponds to the deepest level.  I suspect this is the reason
> for gridptr->dimmin[GZINDEX] == 30 and gzinx == 1 .
>
> Here is how the vertical axis is defined (from ncdump -h):
>
>  float dep(dep) ;
>    dep:units = "meters" ;
>    dep:axis = "Z" ;
>    dep:positive = "down" ;
>
>  dep = 5, 15, 25, 35, 45, 55, 65, 75, 85, 95, 105, 115.9789, 129.7985,
>     148.0428, 171.8625, 201.8625, 238.0428, 279.7985, 325.9789,
> 375, 425,
>     491.1513, 604.1757, 790.2066, 1068.231, 1448.231, 1930.207,
> 2504.176,
>     3151.151, 3845 ;
>
> I can send you my netCDF file as well as an instruction on how to
> reproduce the segmentation fault.
>
> I'm using grads-1.9b4 on Linux.
>
> Regards,
> Ryo



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://gradsusr.org/pipermail/gradsusr/attachments/20080220/f9bba429/attachment.html