[geos-devel] is this a big leak?

[strk]

I've parametrized Dave's test6.cpp so that first argument
is the number of calls to op() and second argument is the
global offset used. With the code updated by Yurj I continue
to get still-reachable memory growing as the number of calls
to union grow. 

$ vg ./test6 1 15
==22612==    still reachable: 22432 bytes in 22 blocks.

$ vg ./test6 10 15
==22613==    still reachable: 61360 bytes in 32 blocks.

The test I used to detect the leak initially run again gaves
the same results.

strk wrote:
> Geometry set size is about 2MB:
>   gis=# select sum(mem_size(the_geom)) from world where gid < 50;
>   2148316
> 
> Initial postmaster process status is:
>   PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME COMMAND
>   566 pgsql     15   0  3288 3288  2684 S     0.0  0.4   0:00 postmaster
> 
> After query:
>   gis=# select box(unite(the_geom)) from plmshp02_1 where gid < 50;
>   (180,83.1138763427734),(-180,-90)
> 
> The postmaster grew of about 66M (having touched a 78MB upper limit):
>   PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME COMMAND
>   566 pgsql     19   0 71472  69M  3396 S     0.0  9.2   3:35 postmaster
> 
> If I run that again, *exactly the same query*:
>   PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME COMMAND
>   566 pgsql     14   0  126M 126M  3396 S     0.0 16.8   7:13 postmaster

Also the segfault is still there, but I could not isolate it yet.

--strk;

pramsey wrote:
> Great news! Time to run the conformance test suite again :)
> 
> On Thursday 02 October 2003 18:21, Yury A. Bychkov wrote:
> > I've just fixed that leak in Overlay and committed the code to CVS.
> >
> > Yury