[gdal-dev] Memory leaks?

Ed McNierney ed at t...
Mon Aug 26 23:06:31 EDT 2002


Paul -

No, that's not the same thing at all. The call to GDALAllRegister ()
*loads* all the configured drivers, but it does not *open* them. For
example, in the GeoTIFF driver, the call to GDALAllRegister () calls (in
the driver) GDALRegister_GTiff (), which registers the driver by
allocating a data structure for it and filling it in. This is pretty
much what all drivers do at registration time. There is no equivalent
"GDALUnregister_Gtiff" function to undo this operation, and so there is
no equivalent "GDALUnregistter_Gtiff" function in the driver.

The constructor and destructor for the class GTiffDataset are not called
at registration time. They're called much later if and when there's an
actual dataset for that driver to handle, and the destructor is indeed
properly called when the dataset is no longer needed. If it were not
being called, your memory leak tester would be reporting allocations
from other than GDALAllRegister that were left over.

At the GDALAllRegister level, there's no "destructor" to be called, so
the failure to call it doesn't create a problem for any driver.

- Ed

-----Original Message-----
From: Paul Selormey [mailto:paul at t...] 
Sent: Monday, August 26, 2002 10:41 PM
To: gdal-dev at yahoogroups.com
Subject: Re: [gdal-dev] Memory leaks?



Hello Ed,

> (at the risk of pushing this thread over the edge into a religious
> debate...)

I am not interested in debating an issue for the sake of debate, there
is not time for this.

> While it would be nice to offer a complementary "close and clean up" 
> function for the library, I can't agree that it's wrong to not have 
> one.

I think you have already made the point. If you agree, however, that the
destructors are not called, then have a look at the destructors for each
driver to see what they really do, and decide whether it is a choice to
clean up or not - this concludes my contribution to this issue.

Best regards,
Paul.



 

Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/ 






More information about the Gdal-dev mailing list