Opened 15 years ago

Last modified 14 years ago

#841 closed defect

transformTo() memory leak — at Initial Version

Reported by: hobu Owned by: warmerdam
Priority: high Milestone:
Component: OGR_SRS Version: unspecified
Severity: normal Keywords:


IRC Log:

hobu_work	any ideas why this would just continue to consume gobs of memory?
hobu_work	what am I forgetting to destroy?
FrankW	hobu_work: I don't see any obvious source of problems. Perhaps there 
        is an issue in transformTo.
hobu_work	I modified it to this 
            and took out all of the Clone()'s and it still grows just as fast 
            (this is a 300k oracle table I'm dumping out to WKT)
FrankW	Can you dump the table to shapefile, and run against that instead? 
        That would help isolate whether it is an oracle problem or not.
FrankW	Another quick test would be to try removing the transformTo() call 
        and see if that makes a difference.
hobu_work	removing the TransformTo does not slow the memory consumption down...
hobu_work	I take that back... removing the TransformTo (both of them) 
            *does* limit the memory consumption
hobu_work	like so...
FrankW	Ah, I didn't notice you were calling get_zone() each time.
FrankW	If you enable the main transformTo is there still a leak?
hobu_work	yes
FrankW	Are these lines? Polygons? Points?
hobu_work	Poly's
hobu_work	with small 4-40 pts in them
hobu_work	is looking at OGRErr OGRGeometry::transformTo( OGRSpatialReference *poSR )
FrankW	I looked through transform() which it calls, and it seems OK.
FrankW	Ahh
FrankW	The problem may be with cleaning up the transformer which is 
        created and destroyed each time.
hobu_work	the delete poCT; statement?
FrankW	Yes, but it is possible that the OGRCoordianteTransformation 
        destructor isn't as clean as it ought to be.
FrankW	Yes, I think I see.
FrankW	the new srs is assigned to the geometries, but the ~OGRGeometry() method 
        does not delete the SRS if the reference count falls to zero, though it 
        does dereference it.
FrankW	This is because some driver implementations personally destroy the 
        OGRSpatialReference for themselves (which they assign to their geometries) 
        assuming that no one else could be still referencing them.
FrankW	So I broke the normal reference counting rules for geometries to avoid 
        causing crashes in esoteric circumstances.
FrankW	You are welcome to file a bug on this (include my text above), but I'm 
        not likelyi to fix it right away.
FrankW	Of course, there could be more going on. I'll likely need to prepare a 
        small c++ test program I can easily run under valgrind to be sure. 

Python Code:
import sys
import os
import ogr
import osr
zones = {10:[-126,-120],
ref = osr.SpatialReference()
def get_zone(point):
    #point2 = point.Clone()
    minx = maxx = point.GetEnvelope()[0]
    for i in zones:
        min,max =,zones[i])
        if minx > min and minx < max:
            min_utmzone = 26900+i
        if maxx > min and maxx < max:
            max_utmzone = 26900+i
    if min_utmzone == max_utmzone:
        return min_utmzone
esri_lines =
in_ref = osr.SpatialReference()
out_ref = osr.SpatialReference()
f = open(r'd:\scott_psu.txt','wb')
lyr = ogr.Open('OCI:username/').GetLayer(0)
feat1 = lyr.GetNextFeature()
while feat1:
    geom = feat1.GetGeometryRef()
   # zone =  get_zone(geom)
    zone = 26910
    outstring = '%s,%s,%s,%s,%s\n'
    outstring = outstring %(feat1.STATE, feat1.COUNTY, feat1.PSU, zone,
    feat1 = lyr.GetNextFeature()

Change History (0)

Note: See TracTickets for help on using tickets.