Memory leak in geos trunk

[bradh]

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.

[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.

[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...

[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.

[strk]

Ticket retargeted after milestone closed

[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?