double free or corruption in vrt with gcp's

[schut@…]

[lazyness: I just copied the corresponding mailing list post describing the bug.]

I have some problems using warped vrt files with gcp's, and I'd
appreciate it if someone could shed some light on it. The situations is
as follows:

o ASTER L2 imagery (hdf) is converted to a warped vrt file using
"gdalwarp -of vrt -srcnodata 0 -dstnodata 0 -s_srs "EPSG:4326" -t_srs
"EPSG:4326" -rcs
HDF4_EOS:EOS_SWATH:"${hdfvnir}":SurfaceReflectanceVNIR:Band${band}
tmp.vnir.${band}.vrt
(don't focus on the file names, it's batch processing). This works ok.
The resulting vrt file is attached and looks good.

o Then whatever I try to do on this file fails with a segfault or the
following error: *** glibc detected *** double free or corruption (out):
0x00000000005a7d90 ***
Aborted (core dumped)

For simplicity's sake I'll show the output of "gdalinfo tmp.vnir.1.vrt"
 (actually I want to do gdal_translate, but the error also appears with
gdalinfo):

Driver: VRT/Virtual Raster
Size is 5507, 4882
Coordinate System is:
GEOGCS["WGS 84",
    DATUM["WGS_1984",
        SPHEROID["WGS 84",6378137,298.257223563,
            AUTHORITY["EPSG","7030"]],
        AUTHORITY["EPSG","6326"]],
    PRIMEM["Greenwich",0,
        AUTHORITY["EPSG","8901"]],
    UNIT["degree",0.01745329251994328,
        AUTHORITY["EPSG","9122"]],
    AUTHORITY["EPSG","4326"]]
Origin = (112.808259,0.315868)
Pixel Size = (0.00013521,-0.00013521)
Corner Coordinates:
Upper Left  ( 112.8082592,   0.3158685) (112d48'29.73"E,  0d18'57.13"N)
Lower Left  ( 112.8082592,  -0.3442274) (112d48'29.73"E,  0d20'39.22"S)
Upper Right ( 113.5528614,   0.3158685) (113d33'10.30"E,  0d18'57.13"N)
Lower Right ( 113.5528614,  -0.3442274) (113d33'10.30"E,  0d20'39.22"S)
Center      ( 113.1805603,  -0.0141794) (113d10'50.02"E,  0d 0'51.05"S)
Band 1 Block=512x128 Type=Int16, ColorInterp=Undefined
  NoData Value=0
*** glibc detected *** double free or corruption (out):
0x00000000005a7d90 ***
Aborted (core dumped)

And here is the backtrace of "gdb gdalinfo core":

#0  0x0000002a9816be69 in kill () from /lib/libc.so.6
#1  0x0000002a95fe9891 in pthread_kill () from /lib/libpthread.so.0
#2  0x0000002a95fe9c12 in raise () from /lib/libpthread.so.0
#3  0x0000002a9816bb62 in raise () from /lib/libc.so.6
#4  0x0000002a9816cef2 in abort () from /lib/libc.so.6
#5  0x0000002a981a3e14 in malloc_usable_size () from /lib/libc.so.6
#6  0x0000002a981a48da in free () from /lib/libc.so.6
#7  0x0000002a958bc150 in VSIFree () from /usr/local/lib/libgdal.so.1
#8  0x0000002a958ca42d in GDALDestroyWarpOptions () from
/usr/local/lib/libgdal.so.1
#9  0x0000002a958d3b4e in GDALWarpOperation::WipeOptions() () from
/usr/local/lib/libgdal.so.1
#10 0x0000002a958d3ab9 in GDALWarpOperation::~GDALWarpOperation() ()
from /usr/local/lib/libgdal.so.1
#11 0x0000002a9589d6f4 in VRTWarpedDataset::~VRTWarpedDataset() () from
/usr/local/lib/libgdal.so.1
#12 0x0000002a958a9df9 in GDALClose () from /usr/local/lib/libgdal.so.1
#13 0x0000000000402e59 in main ()

Alas I'm on amd64 and valgrind has not yet been ported to that arch.

I'm using a fresh gdal from cvs, and gentoo linux on amd64. In this
case, GDAL has been compiled without any optimization.

[schut@…]

example vrt file

[schut@…]

OK, I tackled down the problem a little:

I get an errorless performance and apparently correct output when I
comment some CPLFree's in alg/gdalwarper.cpp, as in the code chunk below
(line 743-757):

void CPL_STDCALL GDALDestroyWarpOptions( GDALWarpOptions *psOptions )

{
//     CSLDestroy( psOptions->papszWarpOptions );
//     CPLFree( psOptions->panSrcBands );
//     CPLFree( psOptions->panDstBands );
//     CPLFree( psOptions->padfSrcNoDataReal );
//     CPLFree( psOptions->padfSrcNoDataImag );
//     CPLFree( psOptions->padfDstNoDataReal );
//     CPLFree( psOptions->padfDstNoDataImag );
//     CPLFree( psOptions->papfnSrcPerBandValidityMaskFunc );
//     CPLFree( psOptions->papSrcPerBandValidityMaskFuncArg );

    CPLFree( psOptions );
}

Note that I'm used to the luxury of python garbage collection so I guess
that what I did results in not really correct c++ code and might even be
dangerous, but at least it works, and I hope this is enough hint to one
of the main developers to create a real fix.

[warmerdam]

Fixed. 

The problem was that the "dstnodatavalue" was not being copied properly
in GDALCloneWarpOptions() in gdal/alg. 

I have also fixed a few other memory leaks I found while working on this.