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

[netCDF #MJR-379092]: more information about segmentation fault in ncdump when dumping HDF5 string

Kent,

> > Fixed-size HDF5 string is very commonly used inside HDF5 files that users
> > are interested in making netCDF-4 to access.
> > I happened to find an old  report regarding this issue. The student did
> > some investigations and provided a patch for the netcdf-4 package.
> > Hopefully this can help you guys fix the bug.
> >
> > Check
> > ftp://ftp.hdfgroup.uiuc.edu/pub/outgoing/ymuqun/temp/netcdf_seg_fault/old-report/
> >
> >
> > especially README can help you get started.
> 
> Yes, that's very helpful, although the fix has become more complex since we 
> added a
> dispatch layer.  Nevertheless, I'll commit to getting the fix into the 4.2.1 
> release,
> which we're aiming to make available in the next two or three weeks.
> 
> Another complication is our inability to include a simple test that just uses 
> the
> netCDF-4 API, because our data model doesn't support HDF5's fixed-length 
> string
> type.  Nevertheless, we may be able to just include a simple HDF5 file that 
> uses
> it to make sure we can read it.

Although I already responded to the earlier ticket, I'm also responding to and 
closing
this one.  I'm not including a test .h5 file in the distribution, but instead 
generating
one as part of the test program for the fixes ...

--Russ

> > address@hidden> wrote:
> >
> > > Hi Kent,
> > >
> > > Thanks for all your work on isolating the bug.
> > >
> > > I think the problem may be that netCDF-4 has no such type
> > > as a "fixed length string", it only has the "string" type,
> > > which is always variable length, and an "array of char"
> > > type, which was in the netCDF-3 classic model, and for
> > > which a dimension must be defined and named to identify
> > > the langth of the char array.
> > >
> > > When Ed added support for reading HDF5 files that were not
> > > netCDF-4 files, he may have not realized fixed-length chars
> > > were a new type that the netCDF-4 data model does not support.
> > > They either have to be converted to variable length strings
> > > (perhaps with a hidden attribute indicating they are fixed
> > > length) or as array of char, with a new dimension defined
> > > that does not correspond to an associated HDF5 dataspace.
> > >
> > > Or, we have to add support for a new type, which is a lot of
> > > work.
> > >
> > > The netCDF-4 data model supports fixed-size arrays as members
> > > of structs, without having to define associated named dimensions.
> > > But as far as I understand, it does not support fixed-size arrays
> > > that have no associated, named dimensions.
> > >
> > > I'll have to look at this a little more carefully to verify that
> > > the problem is in the netCDF-4 library layer rather than ncdump,
> > > but if so, the fix will have to be in the library.
> > >
> > > --Russ
> > >
> > > Russ Rew                                         UCAR Unidata Program
> > > address@hidden                      http://www.unidata.ucar.edu
> > >
> > >
> > >
> > > Ticket Details
> > > ===================
> > > Ticket ID: MJR-379092
> > > Department: Support netCDF
> > > Priority: Normal
> > > Status: Closed
> > >
> > >
> >
> >
> > --
> > Kent Yang The HDF Group
> > 1800 So. Oak St., Suite 203, Champaign, IL 61820
> > 217.531.6107
> > http://hdfgroup.org http://hdfeos.org
> >
> >
> 
> Russ Rew                                         UCAR Unidata Program
> address@hidden                      http://www.unidata.ucar.edu
> 
> 

Russ Rew                                         UCAR Unidata Program
address@hidden                      http://www.unidata.ucar.edu



Ticket Details
===================
Ticket ID: MJR-379092
Department: Support netCDF
Priority: Critical
Status: Closed