[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