Ticket #1331 (closed defect: fixed)

Opened 2 years ago

Last modified 1 year ago

HDF4 EOS case EOS GRID memory error.

Reported by: denis.nadeau@gmail.com Assigned to: warmerdam
Priority: normal Milestone: 1.4.2
Component: GDAL_Raster Version: unspecified
Severity: major Keywords: hdf
Cc:

Description (Last modified by warmerdam) 

hdf4imagedataset.cpp line 2221
poDS->iBandDim = i;

When Dimension List does not have the word "Band", this variable never get set and it is initialized to -1 in the constructor.  This cause a memory error in IReadBlock method.

hdf4imagedataset.cpp line 429
aiStart[poGDS->iBandDim] = nBand - 1;
aiEdges[poGDS->iBandDim] = 1;

aiEdges[-1]=1  on my machine cause eERR variable to be set to CPL_DEBUG and causing a faulty GDAL Read error, for eERR should be CPL_None when IReadBlock returns.

I guess in the 3D array case this should be set to 0.

Denis

Change History

10/19/06 18:57:43 changed by denis.nadeau@gmail.com 

This condition works for me.  I assume that X and Y dimension will
have X or Y in there name. 

line 2221
                    for ( i = 0; i < nDimCount; i++ )
                    {
                        if ( !(strstr( papszDimList[i], "X" )) &&
			     !(strstr( papszDimList[i], "Y" )) )
                        {

03/27/07 00:23:05 changed by warmerdam

  • priority changed from highest to normal.
  • status changed from new to assigned.
  • description changed.
  • milestone set to 1.4.1.

Denis,

I ran into this today, and put a bunch of fixes in related to this area of code.

Can you verify that the trunk version of GDAL fixes the problem you were seeing?

04/03/07 15:49:51 changed by warmerdam

  • milestone changed from 1.4.1 to 1.4.2.

Deferring to 1.4.2 pending feedback from Denis.

04/21/07 13:04:36 changed by warmerdam

  • keywords set to hdf.

Bump ... when you get a chance I'd appreciate your checking this Denis.

04/23/07 15:09:35 changed by dnadeau

Frank,

I was revising this bug, the code runs, but there is an aiStart[-1] on line 350. 

                    aiStart[poGDS->iBandDim] = nBand - 1;
                    aiEdges[poGDS->iBandDim] = 1;

gdal_translate always produce the same results using different bands using this file: AIRS.2002.09.17.L3.RetStd?008.v4.0.9.0.G06086155227.hdf

I also used subdataset: HDF4_EOS:EOS_GRID:"AIRS.2002.09.17.L3.RetStd008.v4.0.9.0.G06086155227.hdf":descending_MW_only:GPHeight_MW_D_ct

poGDS->iBandDim should be initialized to "the 3rd dimension" for 3D case

Ex: 

If
YDim=1
XDim=2

then,
iBandDim=0

Here is the location of the file I used. ftp://g0dup05u.ecs.nasa.gov//datapool/OPS/user/services/OPS/opendap/AIRS/AIRX3ST8.003/2002.09.17

04/23/07 16:34:00 changed by warmerdam

  • status changed from assigned to closed.
  • resolution set to fixed.

I have confirmed serious holes in the iBandDim selection logic for EOS_GRID datasets. I have committed fixes as r11340 (trunk) and r11341 (branches/1.4). Testing with your datasets shows things operating ok.

I also noticed that access to later bands of that dataset are extremely slow. GDAL reads individual scanlines via GDreadfield(), and it appears that to read a given scanline all the previous scanlines of this band, and the complete data of previous bands needs to be decompressed. Yikes! I don't know how common use of this sort of compression is in HDF4 EOS_GRID products, but it is super-painful. If this resurfaces as a major issue, we could improve performance by using a larger block size but that still is a pretty poor solution.

Please re-open if you still see bugs with EOS_GRID products.