[gdal-dev] [gdal 3.12beta] Normal chain of explicit destruction does not work with ComputedDataset

[Momtchil Momtchev]

Is there any way to know whether this is a GDALComputedDataset if 
everything I have is a GDALDataset pointer?

On 24/10/2025 12:55, Even Rouault wrote:
>
> Hi,
>
> you should not destroy the dataset of a GDALComputedRasterBand. The 
> GDALComputedRasterBand destructor does that automatically.
>
> Even
>
> Le 24/10/2025 à 12:40, Momtchil Momtchev via gdal-dev a écrit :
>>
>> I have modified one of the algebra examples as follows:
>>
>> #include<gdal_priv.h>
>> intmain() {
>> GDALAllRegister();
>> autopoDS=std::unique_ptr<GDALDataset>(GDALDataset::Open("test/data/a39se10.jpg"));
>> auto&R=*(poDS->GetRasterBand(1));
>> auto&G=*(poDS->GetRasterBand(2));
>> auto&B=*(poDS->GetRasterBand(3));
>> GDALRasterBand*graylevel=newGDALComputedRasterBand((0.299*R+0.587*G+0.114*B).AsType(GDT_Byte));
>> autopoGTiffDrv=GetGDALDriverManager()->GetDriverByName("GTiff");
>> std::unique_ptr<GDALDataset>(
>> poGTiffDrv->CreateCopy("graylevel.tif", graylevel->GetDataset(), 
>> false, nullptr, nullptr, nullptr))
>> .reset();
>> GDALDataset*dh=graylevel->GetDataset();
>> deletegraylevel;
>> dh->Close();
>> return0;
>> }
>>
>> I allocate graylevel on the heap, I obtain a pointer to the 
>> GDALComputedDataset and I attempt to destroy first the 
>> GDALComputedRasterBand then the GDALComputedDataset. This fails with 
>> a crash in Close. Is this a bug or am I not supposed to do this? I am 
>> doing it, because this is the usual chain of destruction events for 
>> objects returned to JS. RasterBands hold a reference to their Dataset 
>> in order to prevent the object from being GCed.
>>
>> -- 
>> Momtchil Momtchev<momtchil at momtchev.com>
>>
>> _______________________________________________
>> gdal-dev mailing list
>> gdal-dev at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/gdal-dev
> -- 
> http://www.spatialys.com
> My software is free, but my time generally not.

-- 
Momtchil Momtchev<momtchil at momtchev.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20251024/f10b4990/attachment.htm>