bug report: grib1 decoding, missing times results in seg fault

From: David P. Wojtowicz <davidw_at_nyahnyahspammersnyahnyah>
Date: Thu, 11 Dec 2008 17:26:29 -0600 (CST)

Hi,

I've noticed the following bug in NCL. (happens with 4.3.1 binary and self-compiled 5.0.0, both on linux)

I have file containing grib1 products saved by pqact from LDM. For whatever reason, some of the fields are missing at some of the forecast times. (It seems to be a consistent problem with the GFS 211 files I'm saving, but could happen for any product)

I have a simple NCL test script that looks like this:

----
g=addfile("GFS-211-2008121100.grib1","r")
print(g)
----

This is essentially the same as ncl_filedump (and in fact ncl_filedump has the same problem)

I get a series of warnings, noting the missing data, that look like this (only two copied for brevity):

warning:GFS-211-2008121100.grib1->V_VEL_211_ISBL_10 is missing ft: 126 lv: 100
warning:GFS-211-2008121100.grib1->V_VEL_211_ISBL_10 is missing ft: 126 lv: 150

Then it crashes with a segmentation fault. I presume the correct operation is to warn about the missing data, but continue on and just return missing values when trying to access the missing parts of the data.

I've debugged this and traced it to ni/src/ncl/NclGRIB.c line 3148. Here is the code fragment.

dstep = therec->grid_dims;
while(dstep != NULL) {
if((dstep->dim_inq->is_gds == step->gds_type)&&
(GdsCompare(dstep->dim_inq->gds,dstep->dim_inq->gds_size,
step->thelist->rec_inq->gds,step->thelist->rec_inq->gds_size))) {
^^^^^^^^^^^^^^^^^^^^
if ((step->gds_type == 203) && (dstep->dim_inq->is_uv != Is_UV(step->param_number))) {
dstep = dstep->next;
continue;
}
break;
} else {
dstep = dstep->next;
}
}

The problem is marked with ^^^^^^^^. Apparently step->thelist->rec_inq goes NULL at some point before dstep does, resulting in a NULL reference and thus a segfault.

I've temporarily solved it by adding a line "if(step->therec->rec_inq == NULL) break;" just inside the while loop. However the code is rather complex here and I'm not sure that's the appropriate solution.... though it does seem to work... though I haven't tested all aspects of file access under this fix.

If you want to reproduce it, you can grab the grib file from here:

http://www.atmos.uiuc.edu/~davidw/GFS-211-2008121100.grib1

running "ncl_filedump -c" on it should produce the error.

Thanks.

----
David Wojtowicz, Sr. Research Programmer
IT Coordinator - School of Earth, Society and the Environment (SESE)
University of Illinois at Urbana-Champaign
davidw_at_uiuc.edu 217-333-8390

_______________________________________________
ncl-talk mailing list
List instructions, subscriber options, unsubscribe:
http://mailman.ucar.edu/mailman/listinfo/ncl-talk
Received on Thu Dec 11 2008 - 16:26:29 MST

This archive was generated by hypermail 2.2.0 : Mon Feb 02 2009 - 07:53:06 MST