Opened 19 years ago

Last modified 19 years ago

#908 closed defect (worksforme)

memory leak with OGR virtual layers

Reported by: sgillies@… Owned by: warmerdam
Priority: high Milestone:
Component: default Version: unspecified
Severity: normal Keywords:
Cc:

Description

Frank, I'm using ogr.py in a project and am experiencing a leak related to
spatial references when using an OGR virtual dataset. I've run my project's
unittests under valgrind and see the following leak report:

==28473== 40 bytes in 1 blocks are possibly lost in loss record 28 of 61
==28473==    at 0x1B904BF7: operator new(unsigned) (vg_replace_malloc.c:133)
==28473==    by 0x1C30FC23: OGRSpatialReference::Clone() const (in
/usr/local/lib/libgdal.so.1.2.6)
==28473==    by 0x1C2EB295: OGRVRTLayer::Initialize(_CPLXMLNode*, char const*)
(in /usr/local/lib/libgdal.so.1.2.6)
==28473==    by 0x1C2EA545: OGRVRTDataSource::Initialize(_CPLXMLNode*, char
const*) (in /usr/local/lib/libgdal.so.1.2.6)
==28473==
==28473==
==28473== 11000 bytes in 275 blocks are definitely lost in loss record 52 of 61
==28473==    at 0x1B904BF7: operator new(unsigned) (vg_replace_malloc.c:133)
==28473==    by 0x1C30FC23: OGRSpatialReference::Clone() const (in
/usr/local/lib/libgdal.so.1.2.6)
==28473==    by 0x1C2EB295: OGRVRTLayer::Initialize(_CPLXMLNode*, char const*)
(in /usr/local/lib/libgdal.so.1.2.6)
==28473==    by 0x1C2EA545: OGRVRTDataSource::Initialize(_CPLXMLNode*, char
const*) (in /usr/local/lib/libgdal.so.1.2.6)
==28473==
==28473== LEAK SUMMARY:
==28473==    definitely lost: 11000 bytes in 275 blocks.
==28473==    possibly lost:   40 bytes in 1 blocks.
==28473==    still reachable: 2100304 bytes in 21746 blocks.
==28473==         suppressed: 200 bytes in 1 blocks.

275 is probably the number of times I am calling GetLayer() or GetLayerByName().

Attachments (1)

bug-908.tar.gz (1.8 KB ) - added by sgillies@… 19 years ago.
script, ovf file, and python suppressions

Download all attachments as: .zip

Change History (5)

comment:1 by warmerdam, 19 years ago

Sean,

I haven't succeeded in reproducing this.  Could you provide a .vrt file 
that demonstrates the problem with ogrinfo?  You might also want to try
getting more detailed leak trackbacks with --leak-resolution=high --num-callers=10

by sgillies@…, 19 years ago

Attachment: bug-908.tar.gz added

script, ovf file, and python suppressions

comment:2 by warmerdam, 19 years ago

Sean,

I get:

  warmerda@gdal2200[74]% vgp python error.py
==15149== Memcheck, a memory error detector for x86-linux.
==15149== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al.
==15149== Using valgrind-2.4.0, a program supervision framework for x86-linux.
==15149== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al.
==15149== For more details, rerun with: -v
==15149== 
OGR: OGROpen(/home/warmerda/mapserver/tests/point.shp) succeeded (0x25b8fb20).
OGR: OGROpen(/home/warmerda/mapserver/tests/line.shp) succeeded (0x25b94b68).
OGR: OGROpen(/home/warmerda/mapserver/tests/polygon.shp) succeeded (0x259e5318).
OGR: OGROpen(test.ovf) succeeded (0x27189880).
VRT: 1 features read on layer 'point'.
OGR: ReleaseDataSource(/home/warmerda/mapserver/tests/point.shp/0x25b8fb20)
dereferenced and now destroying.
Shape: 1 features read on layer 'point'.
OGR: ReleaseDataSource(/home/warmerda/mapserver/tests/line.shp/0x25b94b68)
dereferenced and now destroying.
OGR: ReleaseDataSource(/home/warmerda/mapserver/tests/polygon.shp/0x259e5318)
dereferenced and now destroying.
{'typename': 'point', 'srs': 'GEOGCS["WGS 84",DATUM["WGS_1984",SPHEROID["WGS
84",6378137,298.257223563,AUTHORITY["EPSG","7030"]],TOWGS84[0,0,0,0,0,0,0],AUTHORITY["EPSG","6326"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9108"]],AXIS["Lat",NORTH],AXIS["Long",EAST],AUTHORITY["EPSG","4326"]]',
'bounds': (0.0, 51.477221999999998, 0.0, 51.477221999999998), 'schema': [['FID',
'int'], ['FNAME', 'string']]}
==15149== 
==15149== FILE DESCRIPTORS: 3 open at exit.
==15149== Open file descriptor 2: /dev/pts/1
==15149==    <inherited from parent>
==15149== 
==15149== Open file descriptor 1: /dev/pts/1
==15149==    <inherited from parent>
==15149== 
==15149== Open file descriptor 0: /dev/pts/1
==15149==    <inherited from parent>
==15149== 
==15149== 
==15149== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 1540 from 8)
==15149== malloc/free: in use at exit: 957791 bytes in 435 blocks.
==15149== malloc/free: 5719 allocs, 5284 frees, 2582136 bytes allocated.
==15149== For counts of detected errors, rerun with: -v
==15149== searching for pointers to 435 not-freed blocks.
==15149== checked 4312208 bytes.
==15149== 
==15149== LEAK SUMMARY:
==15149==    definitely lost: 0 bytes in 0 blocks.
==15149==      possibly lost: 0 bytes in 0 blocks.
==15149==    still reachable: 957791 bytes in 435 blocks.
==15149==         suppressed: 0 bytes in 0 blocks.
==15149== Reachable blocks (those to which a pointer was found) are not shown.
==15149== To see them, rerun with: --show-reachable=yes

Are you using GDAL CVS or an older version? 

comment:3 by sgillies@…, 19 years ago

version 1.2.6

comment:4 by warmerdam, 19 years ago

closing under the assumption it is already fixed.

Note: See TracTickets for help on using tickets.