[gdal-dev] Memory leak from GDALRasterIO
Kevin F Webb
kfw4 at cornell.edu
Thu Jul 29 14:28:01 EDT 2010
Good day!
I am experiencing a memory leak from looped calls to GDALRasterIO(). It may be something I am doing improperly
because I use/call RasterIO() in a C++ program that runs leak free.
I "migrated" the C++ code to the GDAL C API so that I can integrate some really old C code downstream from the GDALRasterIO() call.
The leak was observed on v1.5.2, so I upgraded to 1.7.2 and am experiencing the same effect.
Are there special options or considerations when compiling C code against the GDAL library?
Any suggestions?
KFW
==29880== 736,992 bytes in 10,236 blocks are possibly lost in loss record 1,122 of 1,126
==29880== at 0x4A0666E: operator new(unsigned long) (vg_replace_malloc.c:220)
==29880== by 0x50256FA: GDALRasterBand::GetLockedBlockRef(int, int, int) (gdalrasterband.cpp:1230)
==29880== by 0x5035C94: GDALRasterBand::IRasterIO(GDALRWFlag, int, int, int, int, void*, int, int, GDALDataType, int, int) (rasteri\
o.cpp:228)
==29880== by 0x40CD44: main (fragstatCutter.c:254)
==29880==
==29880== 3,244,032 bytes in 99 blocks are possibly lost in loss record 1,123 of 1,126
==29880== at 0x4A05E1C: malloc (vg_replace_malloc.c:195)
==29880== by 0x50255E6: GDALRasterBand::AdoptBlock(int, int, GDALRasterBlock*) (gdalrasterband.cpp:820)
==29880== by 0x5025732: GDALRasterBand::GetLockedBlockRef(int, int, int) (gdalrasterband.cpp:1242)
==29880== by 0x5035C94: GDALRasterBand::IRasterIO(GDALRWFlag, int, int, int, int, void*, int, int, GDALDataType, int, int) (rasteri\
o.cpp:228)
==29880== by 0x40CD44: main (fragstatCutter.c:254)
==29880==
==29880== 14,709,648 bytes in 1 blocks are possibly lost in loss record 1,124 of 1,126
==29880== at 0x4A05E1C: malloc (vg_replace_malloc.c:195)
==29880== by 0x5051927: VSIMalloc2 (cpl_vsisimple.cpp:622)
==29880== by 0x4EF9837: HFABand::LoadExternalBlockInfo() (hfaband.cpp:406)
==29880== by 0x4EF9C0E: HFABand::LoadBlockInfo() (hfaband.cpp:292)
==29880== by 0x4EFA1B7: HFABand::GetRasterBlock(int, int, void*, int) (hfaband.cpp:1029)
==29880== by 0x4EFD85F: HFARasterBand::IReadBlock(int, int, void*) (hfadataset.cpp:966)
==29880== by 0x5025756: GDALRasterBand::GetLockedBlockRef(int, int, int) (gdalrasterband.cpp:1249)
==29880== by 0x5035C94: GDALRasterBand::IRasterIO(GDALRWFlag, int, int, int, int, void*, int, int, GDALDataType, int, int) (rasteri\
o.cpp:228)
==29880== by 0x40CD44: main (fragstatCutter.c:254)
==29880==
==29880== 41,930,752 bytes in 10,237 blocks are possibly lost in loss record 1,125 of 1,126
==29880== at 0x4A05E1C: malloc (vg_replace_malloc.c:195)
==29880== by 0x50288BF: GDALRasterBlock::Internalize() (gdalrasterblock.cpp:477)
==29880== by 0x502571A: GDALRasterBand::GetLockedBlockRef(int, int, int) (gdalrasterband.cpp:1235)
==29880== by 0x5035C94: GDALRasterBand::IRasterIO(GDALRWFlag, int, int, int, int, void*, int, int, GDALDataType, int, int) (rasteri\
o.cpp:228)
==29880== by 0x40CD44: main (fragstatCutter.c:254)
==29880==
==29880== LEAK SUMMARY:
==29880== definitely lost: 0 bytes in 0 blocks
==29880== indirectly lost: 0 bytes in 0 blocks
==29880== possibly lost: 60,673,946 bytes in 21,287 blocks
==29880== still reachable: 4,295,148,058 bytes in 1,357 blocks
==29880== suppressed: 0 bytes in 0 blocks
==29880== Reachable blocks (those to which a pointer was found) are not shown.
==29880== To see them, rerun with: --leak-check=full --show-reachable=yes ==29880==
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20100729/746c3f61/attachment-0001.html
More information about the gdal-dev
mailing list