[postgis-devel] memory management questions #1

[Mark Cave-Ayland]

Paul Ramsey wrote:

>> Then I have a third question that maybe wrong time to ask since Paul is
>> working on the parser. But I get memory leaks when using lwgeom_from_ewkt
>> looking like this:
>>
>> ==32144== 37 bytes in 1 blocks are definitely lost in loss record 2 of 3
>> ==32144==    at 0x4C274A8: malloc (vg_replace_malloc.c:236)
>> ==32144==    by 0x42BB7F: make_serialized_lwgeom (lwgparse.c:1387)
>> ==32144==    by 0x42CA2A: parse_it (lwgparse.c:1730)
>> ==32144==    by 0x417253: serialized_lwgeom_from_ewkt (lwgeom.c:758)
>> ==32144==    by 0x417DB3: lwgeom_from_ewkt (lwgeom.c:736)
>> ==32144==    by 0x40A02F: test_mindistance2d_tolerance (cu_measures.c:35)
>> ==32144==    by 0x50B32A9: ??? (in /usr/lib/libcunit.so.1.0.1)
>> ==32144==    by 0x50B3ACE: CU_run_test (in /usr/lib/libcunit.so.1.0.1)
>> ==32144==    by 0x411B6B: main (cu_tester.c:138)
> 
> You're in the old parser (parse_it is called) so it's Not My Problem.
> Which isn't to say that my parser won't leak, I am, frankly, being a
> little lazy knowing that palloc/pfree are going to be behind me
> cleaning up the mess.

Right. I discovered this leak when I was testing the new pgsql2shp code 
in trunk, and the short version is that there is an incredibly naive 
piece of coding in the existing parser alloc_tuple() that throws away 
malloc() linked lists in certain circumstances.

I did try and come up with a workaround by tracking lists of lists, but 
that then caused other errors to appear all through the parser. Since it 
was something that could not be fixed without substantial work, I came 
to the conclusion that we're much better off going with Paul's new 
version and investing the time/effort there instead. So I can't see this 
ever getting fixed in the current parser I'm afraid :(


ATB,

Mark.

-- 
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: +44 870 608 0063

Sirius Labs: http://www.siriusit.co.uk/labs