[geos-devel] Was it a big memory leak ?

Thu Oct 9 05:30:51 EDT 2003

Sorry for the delay, I was quite busy today. I am attaching a big file (1673
cases, assembled from a bunch of other tests) that I use for leak checking.
New version of GEOS still leaks quite a bit. I'll start fixing it (and you are
welcome to join :-)) Thursday afternoon.

Yury.
Note: A few of the tests in the attached file will fail (mainly because their
intended result is for another precision model), but don't pay much attention to
that, since it's not designed for correctness.

----- Original Message ----- 
From: "strk" <strk at keybit.net>
To: "GEOS Development List" <geos-devel at geos.refractions.net>
Cc: <me at yury.ca>
Sent: Wednesday, October 08, 2003 2:32 AM
Subject: Re: [geos-devel] Was it a big memory leak ?

> I don't have a good test to check all occurences: the once I've seen
> are now all fixed.
> If you send your big test file we can work togheter on the others.
>
> About caching: I'm trying to test the feature trying to aggregate-union
> boundaries of world nations. It's been running for 50 minutes so far
> and memory usage is 584Mb. I want to see what is going to happen when it
> will hit the up limit of 768M (I disabled any swap). If you want to test
> yourself geometries are the imported shapefiles from ArcView demo data
> (Global200/cntry.shp).
>
> --strk;
>
>
> me wrote:
> > Good news. I was wondering why my memory leak detector didn't complain about
> > that. Since that FAQ says that disabling the caching will slow down things
> > considerably, we should probably leave it as it is.
> >
> > BTW, can you send a message to the list once you finish cascade-patching for
> > getCoordinates(), so that I can start on fixing the leaks it caused (when I
ran
> > the current code on my big test file (1673 tests) I've got 55162 leaks) ?
> >
> > Yury
> >
> > ----- Original Message ----- 
> > From: "strk" <strk at keybit.net>
> > To: <geos-devel at geos.refractions.net>
> > Sent: Wednesday, October 08, 2003 1:09 AM
> > Subject: [geos-devel] Was it a big memory leak ?
> >
> >
> > > It seems it was not, but a feature/bug of the STL library (caching).
> > > valgrind FAQ contains tips on how to disable this binding in gcc
> > > please read and comment on this - I think it should be specified
> > > at configuration time wheter to force this or that behaviour
> > > (when not possible at runtime).
> > >
> > > --strk;
> > >
> > >
> > > ----- Forwarded message from Geoff Alexander <galexander2 at nc.rr.com> -----
> > >
> > > From: "Geoff Alexander" <galexander2 at nc.rr.com>
> > > To: "strk" <strk at keybit.net>, <valgrind-users at lists.sourceforge.net>
> > > Cc: <dblasby at refractions.net>
> > > Subject: Re: [Valgrind-users] still reachable from basic_string (C++)
> > > Date: Tue, 7 Oct 2003 21:19:42 -0400
> > >
> > > Looks like this may be Q14 in the valgrind FAQ
> > > (http://developer.kde.org/~sewardj/docs-1.9.5/FAQ.txt).
> > >
> > > Geoff Alexander
> > >
> > > ----- Original Message -----
> > > From: "strk" <strk at keybit.net>
> > > To: <valgrind-users at lists.sourceforge.net>
> > > Cc: <dblasby at refractions.net>
> > > Sent: Tuesday, October 07, 2003 5:29 PM
> > > Subject: [Valgrind-users] still reachable from basic_string (C++)
> > >
> > >
> > > > Does the following valgrind detect a memory leak in the libstdc++ ?
> > > >
> > > > ==2410== 114048 bytes in 26 blocks are still reachable in loss record 14
> > > of 14
> > > > ==2410==    at 0x4002A9A4: malloc (vg_replace_malloc.c:153)
> > > > ==2410==    by 0x804BB6E: __default_alloc_template<true,
> > > 0>::_S_chunk_alloc(unsigned int, int &)
(/usr/include/g++-3/stl_alloc.h:490)
> > > > ==2410==    by 0x804B95B: __default_alloc_template<true,
> > > 0>::_S_refill(unsigned int) (/usr/include/g++-3/stl_alloc.h:531)
> > > > ==2410==    by 0x402F092B: basic_string<char, string_char_traits<char>,
> > > __default_alloc_template<true, 0> >::replace(unsigned int, unsigned int,
> > > char const *, unsigned int) (/usr/include/g++-3/stl_alloc.h:332)
> > > > ==2410==    by 0x402E78C7: __static_initialization_and_destruction_0
> > > (/usr/include/g++-3/std/bastring.h:223)
> > > > ==2410==    by 0x402E7D69:
> > > geos::TopologyValidationError::TopologyValidationError(int,
> > > geos::Coordinate) (/usr/include/g++-3/stl_map.h:76)
> > > > ==2410==    by 0x402EFB04: (within /extra/geos/lib/libgeos.so.1.0.0)
> > > > ==2410==    by 0x40286855: (within /extra/geos/lib/libgeos.so.1.0.0)
> > > > ==2410==    by 0x4000D1D8: _dl_init (dl-init.c:70)
> > > > ==2410==    by 0x40001DB0: (within /lib/ld-2.2.2.so)
> > > >
> > > >
> > > >
> > > > -------------------------------------------------------
> > > > This sf.net email is sponsored by:ThinkGeek
> > > > Welcome to geek heaven.
> > > > http://thinkgeek.com/sf
> > > > _______________________________________________
> > > > Valgrind-users mailing list
> > > > Valgrind-users at lists.sourceforge.net
> > > > https://lists.sourceforge.net/lists/listinfo/valgrind-users
> > >
> > > ----- End forwarded message -----
> > >
> > > _______________________________________________
> > > geos-devel mailing list
> > > geos-devel at geos.refractions.net
> > > http://geos.refractions.net/mailman/listinfo/geos-devel
> >
> >
> > _______________________________________________
> > geos-devel mailing list
> > geos-devel at geos.refractions.net
> > http://geos.refractions.net/mailman/listinfo/geos-devel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: testLeaksBig.xml
Type: text/xml
Size: 434211 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/geos-devel/attachments/20031009/37135031/testLeaksBig.xml