[geos-devel] is this a big leak?

strk strk at keybit.net
Fri Oct 3 06:09:18 EDT 2003


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



More information about the geos-devel mailing list