[netCDF #ETC-878093]: segmentation fault of ncdump in netCDF-4

Kent,

> For some time we've observed that ncdump cannot dump some HDF5 string data
> properly. It caused segmentation fault. However, ncdump -H can dump the
> header successfully.
> The files  are augmented HDF-EOS5 files that are  netCDF-4 compliant.
> We observed this problem in version netCDF-4.1.1. With the current
> netCDF-4.1.3, we still saw the same problem.
> 
> You can find two example files:
> 
> ftp://ftp.hdfgroup.uiuc.edu/pub/outgoing/donglm/netcdf_seg_fault/grid_1_3d_xyz_aug.h5
> ftp://ftp.hdfgroup.uiuc.edu/pub/outgoing/donglm/netcdf_seg_fault/za_1_3d_yztd_aug.h5
> 
> A detailed report can be found:
> ftp://ftp.hdfgroup.uiuc.edu/pub/outgoing/donglm/netcdf_seg_fault/error_report.txt
> 
> The h5dump output of one file can be found:
> ftp://ftp.hdfgroup.uiuc.edu/pub/outgoing/donglm/netcdf_seg_fault/output_StructMetadata.0_h5dump
> 
> We tested it on a linux 32-bit machine. I think it happens on all platforms.
> 
> This string  is just a simple fixed size string. Although the size is
> relatively large(32000), it should be handled.
> Let me know if you need more information.

Looking at the grid_1_3d_xyz_aug.h5 file, it gets the segfault when trying to 
print
the single-character variable StructMetadata.0 in the Group 

  group: HDFEOS\ INFORMATION {
    variables:
        char StructMetadata.0 ;

    // group attributes:
                :HDFEOSVersion = "HDFEOS_5.1.13" ;
    data:

I'm following what happens in gdb, and at this point the local variables in 
nc4_get_vara
have these values:

len     size_t  1
need_to_convert int     0
break_it        int     0
bufr    void *  0x76c680
d2      int     0
i       int     0
range_error     int     0
retval  int     0
scalar  int     1
fill_value_size int [1024]      
provide_fill    int     0
no_read int     0
fillvalue       void *  0x0
start   hsize_t [1024]  
fmaxdims        hsize_t [1024]  
fdims   hsize_t [1024]  
count   hsize_t [1024]  
xtend_size      hsize_t *       0x0
file_type_size  size_t  1
xfer_plistid    hid_t   167772253
mem_spaceid     hid_t   67108867
file_spaceid    hid_t   67108866
dim     NC_DIM_INFO_T * 0x7fffffffb630
var     NC_VAR_INFO_T * 0x78e770
h5      NC_HDF5_FILE_INFO_T *   0x76a4d0
g       NC_GRP_INFO_T * 0x458543
grp     NC_GRP_INFO_T * 0x76f5d0

and it actually gets the memory fault trying to close the dataspace for this
character scalar:

  exit:
/**   if (var->xtype == NC_CHAR && mem_typeid > 0 && H5Tclose(mem_typeid) < 0)
      BAIL2(NC_EHDFERR);*/
   if (file_spaceid > 0)
   {
      if (H5Sclose(file_spaceid) < 0)
         BAIL2(NC_EHDFERR);

As far as I can see, there's no 32000 character string involved at this point.
I can't see why calling H5Sclose gets a segfault here, so haven't made further
progress in debugging this.  Does any of the above information give you an 
idea of what's going on here?

--Russ


 
> Hi Russ,
> 
> For some time we've observed that ncdump cannot dump some HDF5 string data
> properly. It caused segmentation fault. However, ncdump -H can dump the
> header successfully.
> The files  are augmented HDF-EOS5 files that are  netCDF-4 compliant.
> We observed this problem in version netCDF-4.1.1. With the current
> netCDF-4.1.3, we still saw the same problem.
> 
> You can find two example files:
> 
> ftp://ftp.hdfgroup.uiuc.edu/pub/outgoing/donglm/netcdf_seg_fault/grid_1_3d_xyz_aug.h5
> ftp://ftp.hdfgroup.uiuc.edu/pub/outgoing/donglm/netcdf_seg_fault/za_1_3d_yztd_aug.h5
> 
> A detailed report can be found:
> ftp://ftp.hdfgroup.uiuc.edu/pub/outgoing/donglm/netcdf_seg_fault/error_report.txt
> 
> The h5dump output of one file can be found:
> ftp://ftp.hdfgroup.uiuc.edu/pub/outgoing/donglm/netcdf_seg_fault/output_StructMetadata.0_h5dump
> 
> We tested it on a linux 32-bit machine. I think it happens on all platforms.
> 
> This string  is just a simple fixed size string. Although the size is
> relatively large(32000), it should be handled.
> Let me know if you need more information.
> 
> Thanks,
> 
> Kent
> --
> 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



Ticket Details
===================
Ticket ID: ETC-878093
Department: Support netCDF
Priority: Normal
Status: Closed