Opened 13 years ago

Closed 13 years ago

#1455 closed defect (invalid)

gdal_translate failed in debug

Reported by: gok@… Owned by: warmerdam
Priority: highest Milestone:
Component: GDAL_Raster Version: 1.4.0
Severity: major Keywords:

Description (last modified by warmerdam)

I was suspicious about mixing delete with VSICalloc. In SetBand (line439, gdaldataset.cpp)
you are using VSICalloc/VSIRealloc for new bands, in dtor for GDALDataset (line206)
bands destroyed with delete papoBands[i].
I did check delete poVDS instead of GDALClose(), got the same HEAP message.

Wonder what would be another method to create VRTDataset in GDAL style?


-----Original Message-----
From: Frank Warmerdam []
Sent: Tuesday, January 23, 2007 8:29 AM
To: Gennady Khokhorin
Subject: Re: [Gdal-dev] gdal_translate failed in debug

Gennady Khokhorin wrote:
> Hello, all.
> Debugging gdal_translate got a "User breakpoint" dialog box with diagnostic:
> HEAP[gdal_translate.exe]: Invalid Address specified to RtlFreeHeap( 2f0000, bf10c8 )
> It happens at this call:
> GDALClose( (GDALDatasetH) poVDS ); (line 937, gdal_translate.cpp)
> Looks like VRTSimpleSource::~VRTSimpleSource() is dereferencing 3 bands in GDALClose() 
> and fails on delete poDS (line 1847, gdaldataset.cpp).
> Should it be used VSIFree(papoBands[i]) method instead of delete papoBands[i]; ?


Delete is the appropriate operator for papoBands[i] - these are C++ objects
of base type GDALRasterBand and are allocated with new.

I believe you are seeing this problem because the VRTDataset() is created
with "new" in gdal_translate.cpp, but release with delete inside the
GDAL DLL.  The problem is that in some ways of building on windows you
end up with distinct heaps for the .exe and the GDAL DLL.

I think the solution would be to modify gdal_translate.cpp to call
"delete poVDS" instead of GDALClose().

I'd appreciate it if you could file a bug with your finds, and
my analysis and we will fix this for GDAL 1.4.1.  I may take
a slightly different approach to avoid even calling "new VRTDataset()"
in gdal_translate since this "direct access" is inherently dangerous
due to it being very different from normal operations with GDAL.

Best regards,

> Output result is fine. Release version works fine.
> Image is rgb 3 bands 8 bits/sample. Below is output from gdalinfo
> I'm with gdal 1.4.0, no dwg/dxf support, msvc60 + win2K

Change History (1)

comment:1 Changed 13 years ago by warmerdam

Description: modified (diff)
Resolution: invalid
Status: newclosed


SetBand?() uses VSICalloc()/VSIRealloc() for the papoBand array of pointers, not for the band objects themselves. So use of delete to destroy the bands is appropriate. I think you will find that the papoBands is freed with VSIFree() or CPLFree().

Note: See TracTickets for help on using tickets.