[gdal-dev] Memory leaks?

[Ed McNierney]

Paul -

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

Well, yes, sort of - it IS OK to allocate memory and let the system
clean up. The C++ runtime is supposed to free all memory it allocates
when the application terminates, and most operating systems I know of
(and I know a few) will enforce that rule by freeing all memory blocks
associated with a process when it terminates. I think it is very safe
and perfectly appropriate to allocate memory and leave the deallocation
to the runtime and OS.

The chief disadvantage of this technique when used in C++ is that the
delete operator (i.e. appropriate destructor) is NOT called for any
objects allocated with the new operator. You need to call delete
yourself or it won't get called. If you know that and don't care, then
it's fine to ignore the deletes.

However, this does NOT mean that "there is hardly any reason to worry
about memory management in the C++ application". That's quite a jump.
If you're going to allocate an object REPEATEDLY you're probably going
to want to deallocate it or you'll be in trouble. Calling
GDALAllRegister more than once in a program is (IMHO) a usage error.
There are lots of other reasons to "worry about memory management".

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.

- Ed

Ed McNierney
Chief Mapmaker
TopoZone.com


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



Hello Simon,

> Just read Frank's e-mail. He sees the purpose of this function as an 
> aid to making hunting for real memory leaks less confusing. But I 
> would have thought that any decent memory leak checking software would

> only flag leaks that occur in unreachable memory blocks, which does 
> not include those drivers. But it's been a while since I last used 
> Insure for this kind of thing.

It might be a personal style, I do not leave the memories I have
allocated for the system to clean up (if I do not know, that is a
different story). I have never used Insure, but this is what
Windows-based BoundsChecker (do not know if you consider is decent
memory leak checker) gives:

------------------------------------------------------------------------
----
-------------------------------------------
void * __cdecl operator new(unsigned int) (ceosdataset.cpp (206))
GDALRegister_CEOS ceosdataset.cpp 206 void * __cdecl operator
new(unsigned int) (elasdataset.cpp (653)) GDALRegister_ELAS
elasdataset.cpp 653 void * __cdecl operator new(unsigned int)
(aigdataset.cpp (390)) GDALRegister_AIGrid aigdataset.cpp 390 void *
__cdecl operator new(unsigned int) (aaigriddataset.cpp (462))
GDALRegister_AAIGrid aaigriddataset.cpp 462 void * __cdecl operator
new(unsigned int) (sdtsdataset.cpp (378)) GDALRegister_SDTS
sdtsdataset.cpp 378 void * __cdecl operator new(unsigned int)
(dteddataset.cpp (399)) GDALRegister_DTED dteddataset.cpp 399 void *
__cdecl operator new(unsigned int) (pngdataset.cpp (951))
GDALRegister_PNG pngdataset.cpp 951 void * __cdecl operator new(unsigned
int) (jpgdataset.cpp (597)) GDALRegister_JPEG jpgdataset.cpp 597 void *
__cdecl operator new(unsigned int) (memdataset.cpp (481))
GDALRegister_MEM memdataset.cpp 481 void * __cdecl operator new(unsigned
int) (jdemdataset.cpp (316)) GDALRegister_JDEM jdemdataset.cpp 316 void
* __cdecl operator new(unsigned int) (gifdataset.cpp (603))
GDALRegister_GIF gifdataset.cpp 603 void * __cdecl operator new(unsigned
int) (envisatdataset.cpp (609)) GDALRegister_Envisat envisatdataset.cpp
609 void * __cdecl operator new(unsigned int) (xpmdataset.cpp (415))
GDALRegister_XPM xpmdataset.cpp 415 void * __cdecl operator new(unsigned
int) (pnmdataset.cpp (307)) GDALRegister_PNM pnmdataset.cpp 307 void *
__cdecl operator new(unsigned int) (doq1dataset.cpp (363))
GDALRegister_DOQ1 doq1dataset.cpp 363 void * __cdecl operator
new(unsigned int) (doq2dataset.cpp (449)) GDALRegister_DOQ2
doq2dataset.cpp 449 void * __cdecl operator new(unsigned int)
(envidataset.cpp (786)) GDALRegister_ENVI envidataset.cpp 786 void *
__cdecl operator new(unsigned int) (ehdrdataset.cpp (445))
GDALRegister_EHdr ehdrdataset.cpp 445 void * __cdecl operator
new(unsigned int) (pauxdataset.cpp (1091)) GDALRegister_PAux
pauxdataset.cpp 1091 void * __cdecl operator new(unsigned int)
(mffdataset.cpp (874)) GDALRegister_MFF mffdataset.cpp 874 void *
__cdecl operator new(unsigned int) (hkvdataset.cpp (1045))
GDALRegister_HKV hkvdataset.cpp 1045 void * __cdecl operator
new(unsigned int) (effdataset.cpp (232)) GDALRegister_EFF effdataset.cpp
232 void * __cdecl operator new(unsigned int) (fujibasdataset.cpp (223))
GDALRegister_FujiBAS fujibasdataset.cpp 223 void * __cdecl operator
new(unsigned int) (fitdataset.cpp (1285)) GDALRegister_FIT
fitdataset.cpp 1285 void * __cdecl operator new(unsigned int)
(usgsdemdataset.cpp (584)) GDALRegister_USGSDEM usgsdemdataset.cpp 584
void * __cdecl operator new(unsigned int) (gxfdataset.cpp (310))
GDALRegister_GXF gxfdataset.cpp 310 void * __cdecl operator new(unsigned
int) (gdaldrivermanager.cpp (88)) GetGDALDriverManager
gdaldrivermanager.cpp 88 _strdup (cpl_vsisimple.cpp (289)) VSIStrdup
cpl_vsisimple.cpp 289 void * __cdecl operator new(unsigned int)
(vrtdataset.cpp (259)) GDALRegister_VRT vrtdataset.cpp 259 void *
__cdecl operator new(unsigned int) (geotiff.cpp (3034))
GDALRegister_GTiff geotiff.cpp 3034 void * __cdecl operator new(unsigned
int) (hfadataset.cpp (1700)) GDALRegister_HFA hfadataset.cpp 1700 void *
__cdecl operator new(unsigned int) (sar_ceosdataset.cpp (1413))
GDALRegister_SAR_CEOS sar_ceosdataset.cpp 1413 _realloc
(cpl_vsisimple.cpp (268)) VSIRealloc cpl_vsisimple.cpp 268
------------------------------------------------------------------------
----
-----------------------------------------------------

By your arguments, we could leave any memory allocated, which is used
throughout the lifetime of the application for the system to clean up -
there is hardly a reason to worry about memory management in the C++
application.

Best regards,
Paul.



 

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