Opened 8 years ago

Closed 3 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: master
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 Changed 8 years ago by bradh

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 Changed 8 years ago by strk

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 Changed 8 years ago by bradh

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 Changed 7 years ago by robe

Milestone: 3.4.03.5.0

comment:5 Changed 5 years ago by robe

Milestone: 3.5.03.6.0

comment:6 Changed 4 years ago by strk

Milestone: 3.6.03.7.0

Ticket retargeted after milestone closed

comment:7 Changed 3 years ago by robe

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 Changed 3 years ago by robe

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