Opened 15 years ago

Last modified 15 years ago

#821 closed defect (fixed)

double free or corruption in vrt with gcp's

Reported by: schut@… Owned by: warmerdam
Priority: high Milestone:
Component: GDAL_Raster Version: unspecified
Severity: normal Keywords:


[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
(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

Driver: VRT/Virtual Raster
Size is 5507, 4882
Coordinate System is:
        SPHEROID["WGS 84",6378137,298.257223563,
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/
#1  0x0000002a95fe9891 in pthread_kill () from /lib/
#2  0x0000002a95fe9c12 in raise () from /lib/
#3  0x0000002a9816bb62 in raise () from /lib/
#4  0x0000002a9816cef2 in abort () from /lib/
#5  0x0000002a981a3e14 in malloc_usable_size () from /lib/
#6  0x0000002a981a48da in free () from /lib/
#7  0x0000002a958bc150 in VSIFree () from /usr/local/lib/
#8  0x0000002a958ca42d in GDALDestroyWarpOptions () from
#9  0x0000002a958d3b4e in GDALWarpOperation::WipeOptions() () from
#10 0x0000002a958d3ab9 in GDALWarpOperation::~GDALWarpOperation() ()
from /usr/local/lib/
#11 0x0000002a9589d6f4 in VRTWarpedDataset::~VRTWarpedDataset() () from
#12 0x0000002a958a9df9 in GDALClose () from /usr/local/lib/
#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.

Attachments (1)

tmp.vnir.1.vrt (15.0 KB) - added by schut@… 15 years ago.
example vrt file

Download all attachments as: .zip

Change History (3)

Changed 15 years ago by schut@…

Attachment: tmp.vnir.1.vrt added

example vrt file

comment:1 Changed 15 years ago by 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.

comment:2 Changed 15 years ago by warmerdam


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. 

Note: See TracTickets for help on using tickets.