CGAL users discussion list

[Graham Macpherson <>]

Hi Sebastien,

Do you have any further info on using gcc 4.5?  Is it an isolated problem
related to where I found it, or are there wider implications across CGAL?

Thanks,

Graham


On Monday 17 January 2011 13:40:04 Sebastien Loriot (GeometryFactory) wrote:
> Graham Macpherson wrote:
> > Hi Sebastien,
> >
> > Thanks for the reply.
> >
> > I've checked and I do see the linear memory increase with openSUSE and 
> > not with
> > Ubuntu; the logs I attached to my email are valid.
> >
> > Is it worth investigating if gcc 4.4 vs 4.5 makes a difference?
> >
> You were right, there seems to be a problem when using gcc 4.5.
> I don't know right now what. I'll post here when I have more
> information.
>
> S.
>
>
> > Regards,
> >
> > Graham
> >
> >
> >
> > On Monday 17 January 2011 08:40:52 Sebastien Loriot (GeometryFactory) 
> > wrote:
> >> There is no memory leak in your code.
> >>
> >> Behind the Exact_predicates_exact_constructions_kernel, there are
> >> *a multi-precision number type (for example Gmpq if GMP is available)
> >> *filtering mechanism on constructed objects (such as points)
> >>
> >> In your for loop, you are iteratively summing to your points a vector.
> >> Both implementation details are responsible for the memory increase:
> >>
> >> *The precision needed by the number type to exactly do the sums
> >> requires more precision, thus more space. Running you code with
> >> CGAL::Simple_cartesian<CGAL::Gmpq>, you will observe an increase in
> >> memory usage, but not at each iteration (only when precision of numbers
> >> is increased).
> >>
> >> *the filtering mechanism maintain a DAG of the cascaded constructions.
> >> Each sum create a note in the DAG. This is the real cause of the memory
> >> usage increase in your case.
> >>
> >>
> >> However, I am surprised that you do not observe the memory consumption
> >> increase on Ubuntu.
> >> Can you please check again to confirm whether there is a problem?
> >>
> >> S.
> >>
> >> Graham Macpherson wrote:
> >>> Hello all,
> >>>
> >>> I've found a strange memory problem that I've reproduced in the 
> >>> attached code.
> >>>
> >>> I'm taking the vertices of a Delaunay tessellation, calculating a 
> >>> displacement
> >>> for them, clearing the tessellation, then reinserting the displaced 
> >>> vertices.
> >>> When I run this, the memory use by the process increases linearly with 
> >>> each
> >>> iteration, which is wrong, it should be essentially constant, however:
> >>>
> >>>  + The problem doesn't occur with option A in the attached, only with 
> >>> option B,
> >>>    i.e. when adding a Vector_3 to the point;
> >>>
> >>>  + The problem doesn't occur using
> >>>    Exact_predicates_inexact_constructions_kernel, only with
> >>>    Exact_predicates_exact_constructions_kernel;
> >>>
> >>>  + It doesn't appear on all operating systems - it appears on openSUSE 
> >>> 11.3, but
> >>>    not on Ubuntu 10.04.
> >>>
> >>> Also attached are two log files showing the contrasting behaviour on 
> >>> the two
> >>> operating systems with the code the same.
> >>>
> >>> I've tried on openSUSE 11.3 with gcc 4.5.0 (system compiler) and gcc 
> >>> 4.5.2,
> >>> boost versions 1.40.0, 1.42.0 (system) and 1.45.0, and with CGAL 3.5.1 
> >>> and CGAL
> >>> 3.7, and they all essentially do the same thing.
> >>>
> >>> On Ubuntu I'm using CGAL 3.7, gcc 4.4.3 (system compiler) and boost 
> >>> 1.40.0
> >>> (system).
> >>>
> >>> Note, the memInfo class is one that's part of other libraries I'm 
> >>> using, so it
> >>> won't compile for you, it's only there to show how the output was 
> >>> generated.
> >>>
> >>> Assuming that the addition operation in option B is legitimate, then 
> >>> this looks
> >>> like a bug in a library.  Any suggestions for how to get to the bottom 
> >>> of it?
> >>>
> >>> Best regards,
> >>>
> >>> Graham
> >>>
> >>> --
> >>> Graham Macpherson
> >>>
> >>> OpenCFD Ltd.
> >>> www.openfoam.com
> >>>
> >>> 
> >>> +44 (0)118 9471030
> >>>
> >>> 9 Albert Road
> >>> Caversham
> >>> Reading RG4 7AN
> >>>
> >>>
> >>
> >>
> >>
> >
>
>
>