Opened 12 years ago

Closed 7 years ago

#587 closed defect (wontfix)

Memory leak in geos trunk

Reported by: bradh Owned by: geos-devel@…
Priority: minor Milestone: 3.7.0
Component: Default Version: main
Severity: Unassigned Keywords:
Cc:

Description

I'm working on an application that uses GEOS indirectly (via SpatiaLite). In earlier versions of GEOS, it was valgrind-clean (no memory leaks). With trunk, I see two minor leaks, both of which come from initGEOS().

==7181== 16 bytes in 1 blocks are still reachable in loss record 1 of 2
==7181==    at 0x4C28B35: operator new(unsigned long) (vg_replace_malloc.c:261)
==7181==    by 0x6C7133E: geos::geom::GeometryFactory::GeometryFactory() (GeometryFactory.cpp:86)
==7181==    by 0x6C7400E: geos::geom::GeometryFactory::getDefaultInstance() (GeometryFactory.cpp:728)
==7181==    by 0x6874B5C: initGEOS_r (geos_ts_c.cpp:206)
==7181==    by 0x6872ACD: initGEOS (geos_c.cpp:98)
==7181==    by 0x51B8BFA: spatialite_init (spatialite.c:21708)
==7181==    by 0x40092C: main (check_point_to_tile_wrong_arg_type.c:61)
==7181== 
==7181== 32 bytes in 1 blocks are still reachable in loss record 2 of 2
==7181==    at 0x4C28B35: operator new(unsigned long) (vg_replace_malloc.c:261)
==7181==    by 0x6C74003: geos::geom::GeometryFactory::getDefaultInstance() (GeometryFactory.cpp:728)
==7181==    by 0x6874B5C: initGEOS_r (geos_ts_c.cpp:206)
==7181==    by 0x6872ACD: initGEOS (geos_c.cpp:98)
==7181==    by 0x51B8BFA: spatialite_init (spatialite.c:21708)
==7181==    by 0x40092C: main (check_point_to_tile_wrong_arg_type.c:61)

Note that there is a call to finishGEOS() which cleans up most, but not all, of the memory leak.

I did try investigating this, and deleting the defInstance did fix the memory leak, but it completely broke on threaded applications.

Change History (8)

comment:1 by bradh, 12 years ago

Sorry:

Note that there is a call to finishGEOS() which cleans up most, but not all, of the memory leak.

should read

Note that there is a call to finishGEOS() which cleans up most, but not all, of the memory allocated in initGEOS, resulting in this leak.

comment:2 by strk, 12 years ago

I think it used to be a function static, so automatically created and deleted. Then it turned to heap-allocated but forgot by which reason (there was a reason, but maybe invalid).

In any case it's not a big leak, just a singleton...

comment:3 by bradh, 12 years ago

I agree about the "not a big leak", hence the "minor" priority. In fact, its mostly just a nuisance when using valgrind on my app. It might be easier just to add a suppression.

comment:4 by robe, 11 years ago

Milestone: 3.4.03.5.0

comment:5 by robe, 9 years ago

Milestone: 3.5.03.6.0

comment:6 by strk, 7 years ago

Milestone: 3.6.03.7.0

Ticket retargeted after milestone closed

comment:7 by robe, 7 years ago

This ticket is so old I'm not even sure if it's an issue anymore and don't know how to test it.

strk we keep on pushing this, you think we should just change to a won't fix or verify it is even still an issue?

comment:8 by robe, 7 years ago

Resolution: wontfix
Status: newclosed
Note: See TracTickets for help on using tickets.