gmane.comp.gis.geos.devel

Re: using CoordinateOperation::edit cause memory leaks

Tereza Fiedlerová — 2013-05-22T19:55:59

I understand it now. My problem is solved. Thank you for your help and patience.

Tereza


2013/5/22 Sandro Santilli <strk< at >keybit.net>:

Re: using CoordinateOperation::edit cause memory leaks

Sandro Santilli — 2013-05-22T19:44:01

Please try again.
You're assigning to geosGeom the return from the function, making
the previous value of geosGeom unreachable, thus leaking.

--strk;

Re: using CoordinateOperation::edit cause memory leaks

Tereza Fiedlerová — 2013-05-22T19:23:04


I cannot open your link (403 Forbidden), but with my code posted
before just with line delete geosGeom in the end of main.cpp, I still
get that one leak. Could it be caused by my GEOS version? I'm using
Geos 3.3.3?

Tereza

Re: using CoordinateOperation::edit cause memory leaks

Sandro Santilli — 2013-05-22T18:16:18

I get NO leaks reported by Valgrind with this code:
http://strk.keybit.net/tmp/main.cpp

--strk;

Re: using CoordinateOperation::edit cause memory leaks

Tereza Fiedlerová — 2013-05-22T16:59:05

Hi,

I deleted geosGeom from example and the first leak is gone (thank
you), but the second one concerned wkt [1] doesn't. Do you know how to
solve this one?

Tereza

[1]
==7557== 592 (64 direct, 528 indirect) bytes in 1 blocks are
definitely lost in loss record 11 of 11
==7557==    at 0x4C2C154: operator new(unsigned long) (vg_replace_malloc.c:298)
==7557==    by 0x4ED5CEA:
geos::geom::GeometryFactory::createPolygon(geos::geom::LinearRing*,
std::vector<geos::geom::Geometry*,
std::allocator<geos::geom::Geometry*> >*) const (in
/usr/lib/libgeos-3.3.3.so)
==7557==    by 0x4F09E3E:
geos::io::WKTReader::readPolygonText(geos::io::StringTokenizer*) (in
/usr/lib/libgeos-3.3.3.so)
==7557==    by 0x4F0B053:
geos::io::WKTReader::readGeometryTaggedText(geos::io::StringTokenizer*)
(in /usr/lib/libgeos-3.3.3.so)
==7557==    by 0x4F0B49B: geos::io::WKTReader::read(std::string
const&) (in /usr/lib/libgeos-3.3.3.so)
==7557==    by 0x400EAD: main (in
/host/Users/Tereza/Documents/CVUT-FSv/BP/example/Example)



2013/5/22 Sandro Santilli <strk< at >keybit.net>:

Re: using CoordinateOperation::edit cause memory leaks

Sandro Santilli — 2013-05-22T16:36:50

Tereza, the GeometryEditor::edit method is documented [1] to return
a _new_ Geometry, so it's up to you to delete the one you passed to it,
just do that and all leaks are gone.

[1] http://trac.osgeo.org/geos/browser/tags/3.3.8/include/geos/geom/util/GeometryEditor.h#L118

--strk;

Re: using CoordinateOperation::edit cause memory leaks

Tereza Fiedlerová — 2013-05-22T07:58:20

Hi,

I'm sorry for my long reaction time, but I have still the same problem
and I hope you still can help me. I tried to create a minimal example.
This example returns both my problems - memory leak because of using
WKT and also the problem with GeometryEditorOperation as I wrote
before.
The input is simple wkt polygon and I just trying to change its
position. The main.cpp file is attached to this email.

The output from valgrind --leak-check=full is as follows:

==3366== Memcheck, a memory error detector
==3366== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==3366== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==3366== Command: ./Example
==3366==
==3366==
==3366== HEAP SUMMARY:
==3366==     in use at exit: 1,112 bytes in 22 blocks
==3366==   total heap usage: 82 allocs, 60 frees, 9,200 bytes allocated
==3366==
==3366== 520 (64 direct, 456 indirect) bytes in 1 blocks are
definitely lost in loss record 21 of 22
==3366==    at 0x4C2C154: operator new(unsigned long) (vg_replace_malloc.c:298)
==3366==    by 0x4ED5CEA:
geos::geom::GeometryFactory::createPolygon(geos::geom::LinearRing*,
std::vector<geos::geom::Geometry*,
std::allocator<geos::geom::Geometry*> >*) const (in
/usr/lib/libgeos-3.3.3.so)
==3366==    by 0x4EE1718:
geos::geom::util::GeometryEditor::editPolygon(geos::geom::Polygon
const*, geos::geom::util::GeometryEditorOperation*) (in
/usr/lib/libgeos-3.3.3.so)
==3366==    by 0x4EE1423:
geos::geom::util::GeometryEditor::edit(geos::geom::Geometry const*,
geos::geom::util::GeometryEditorOperation*) (in
/usr/lib/libgeos-3.3.3.so)
==3366==    by 0x400EE1: main (in
/host/Users/Tereza/Documents/CVUT-FSv/BP/Example/Example)
==3366==
==3366== 592 (64 direct, 528 indirect) bytes in 1 blocks are
definitely lost in loss record 22 of 22
==3366==    at 0x4C2C154: operator new(unsigned long) (vg_replace_malloc.c:298)
==3366==    by 0x4ED5CEA:
geos::geom::GeometryFactory::createPolygon(geos::geom::LinearRing*,
std::vector<geos::geom::Geometry*,
std::allocator<geos::geom::Geometry*> >*) const (in
/usr/lib/libgeos-3.3.3.so)
==3366==    by 0x4F09E3E:
geos::io::WKTReader::readPolygonText(geos::io::StringTokenizer*) (in
/usr/lib/libgeos-3.3.3.so)
==3366==    by 0x4F0B053:
geos::io::WKTReader::readGeometryTaggedText(geos::io::StringTokenizer*)
(in /usr/lib/libgeos-3.3.3.so)
==3366==    by 0x4F0B49B: geos::io::WKTReader::read(std::string
const&) (in /usr/lib/libgeos-3.3.3.so)
==3366==    by 0x400EAD: main (in
/host/Users/Tereza/Documents/CVUT-FSv/BP/Example/Example)
==3366==
==3366== LEAK SUMMARY:
==3366==    definitely lost: 128 bytes in 2 blocks
==3366==    indirectly lost: 984 bytes in 20 blocks
==3366==      possibly lost: 0 bytes in 0 blocks
==3366==    still reachable: 0 bytes in 0 blocks
==3366==         suppressed: 0 bytes in 0 blocks
==3366==
==3366== For counts of detected and suppressed errors, rerun with: -v
==3366== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)


I will really appreciate your help. Thanks

Tereza






2013/5/16 Sandro Santilli <strk< at >keybit.net>:
_______________________________________________
geos-devel mailing list
geos-devel< at >lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel

Re: using CoordinateOperation::edit cause memory leaks

Sandro Santilli — 2013-05-16T08:43:29

What I need is a full contained test.
A .cpp file that built and run exposes the leak.
It must include the geometry input.

--strk;

On Wed, May 15, 2013 at 10:42:08PM +0200, Tereza Fiedlerová wrote:

Re: using CoordinateOperation::edit cause memory leaks

Tereza Fiedlerová — 2013-05-15T20:42:08

2013/5/13 Sandro Santilli <strk< at >keybit.net>:

Hi,

I tried to make it easier, but I see it wasn't good idea, so I'm
giving here the necessary code without changes:

vertexgeometryeditoroperation.h
--------------------------------

#ifndef VERTEXGEOMETRYEDITOROPERATION_H
#define VERTEXGEOMETRYEDITOROPERATION_H

// GEOS includes
#include <geos/geom/CoordinateSequence.h>
#include <geos/geom/Geometry.h>
#include <geos/geom/util/CoordinateOperation.h>
#include <geos/geom/CoordinateSequenceFactory.h>

// local includes
#include "geoc.h"

#include <QtGui>

using namespace std;
using namespace geos;
using namespace geos::geom;
using namespace geos::geom::util;

using namespace geoc;
using namespace geoc::geo;
using namespace geoc::alg;
using namespace geoc::edit;

namespace geoc {
namespace edit {

/** Class for editing geometry - snap vertices to the closest points. */

class VertexGeometryEditorOperation: public CoordinateOperation
{

    using CoordinateOperation::edit;

public:

    /// Constructor
    VertexGeometryEditorOperation(  ): closeCoord(NULL),
tolDistance(0), changed(false){}

    /** Set private closeCoord to given coord.
     */
    void setCloseCoordSeq( CoordinateSequence *coord ) { closeCoord = coord; }

    /** Set tolerance distance
      */
    void setTolDistance( double tol ) { tolDistance = tol; }

    /** Return true if geometry was changed
      */
    bool isChanged() { return changed; }

    /** Virtual function for editing geometry - snap to closest vertices.
     * < at >param coordinates Not important.
     * < at >param gGeometry to be edited.
     */
    CoordinateSequence* edit(const CoordinateSequence *coordinates,
const Geometry *g );


private:

    CoordinateSequence *closeCoord;
    double tolDistance;
    bool changed;

};

} //namespace geoc
} //namespace edit

#endif // VERTEXGEOMETRYEDITOROPERATION_H


------------------------------
vertexgeometryoperation.cpp
------------------------------

#include "vertexgeometryeditoroperation.h"

namespace geoc {
namespace edit {

CoordinateSequence* VertexGeometryEditorOperation::edit(const
CoordinateSequence *, const Geometry *geom )
{
    CoordinateSequence* coord = geom->getCoordinates();

    // find closest point from closeCoord
    for ( size_t i = 0; i < coord->getSize(); i++)
    {
        // minimal distance
        double minDist = tolDistance;
        size_t indMin = 0;
        bool isMin = false;

        for ( size_t j = 0; j < closeCoord->getSize(); j++ )
        {
            // compute distance between two tested points
            double dist = coord->getAt(i).distance( closeCoord->getAt(j) );

            if( (0 < dist) && (dist < minDist) )
            {
                minDist = dist;
                indMin = j;
                isMin = true;
            }

        }

        // set new coordinate to the closest point if there is some
        if ( isMin )
        {
            coord->setAt( closeCoord->getAt(indMin), i );
            changed = true;
        }

    }

    return coord;

}

} //namespace geoc
} //namespace edit


--------------------------
function using code above
--------------------------

void VertexSnapper::snapVertices(Geometry *geom, CoordinateSequence *closeCoord)
{

    // create and set geometry editor
    VertexGeometryEditorOperation myOp;
    myOp.setCloseCoordSeq( closeCoord );
    myOp.setTolDistance( tolDistance );

    GeometryEditor geomEdit( geom->getFactory() );

    // set geometry to edited one
    geom=( geomEdit.edit( geom , &myOp ) );


}


Thanks for help in advance,

Tereza

Re: using CoordinateOperation::edit cause memory leaks

Sandro Santilli — 2013-05-13T10:16:15

Hi Tereza, could you include a full testcase, including caller ?

--strk;

On Wed, May 08, 2013 at 01:59:28PM +0200, Tereza Fiedlerová wrote:

using CoordinateOperation::edit cause memory leaks

Tereza Fiedlerová — 2013-05-08T11:59:28

Hello,

I'm trying to edit Geometry using class CoordinateOperation. My
implementation of CoordinateOperation::edit function looks like follows:


CoordinateSequence* VertexGeometryEditorOperation::edit(const
CoordinateSequence *, const Geometry *geom )
{
    CoordinateSequence* coord = geom->getCoordinates();

    for ( size_t i = 0; i < coord->getSize(); i++)
    {
            coord->setAt( closeCoord->getAt(i)+number, i );
    }

    return coord;

}

Everything works fine, but when I check it with walgrind it returned these
memory leaks:

==19845== 168 bytes in 3 blocks are possibly lost in loss record 335 of 426
==19845==    at 0x4C2C154: operator new(unsigned long)
(vg_replace_malloc.c:298)
==19845==    by 0xF206682:
geos::geom::GeometryFactory::createLinearRing(geos::geom::CoordinateSequence*)
const (GeometryFactory.cpp:411)
==19845==    by 0xF211A31:
geos::geom::util::CoordinateOperation::edit(geos::geom::Geometry const*,
geos::geom::GeometryFactory const*) (CoordinateOperation.cpp:38)
==19845==    by 0xF2123D6:
geos::geom::util::GeometryEditor::editPolygon(geos::geom::Polygon const*,
geos::geom::util::GeometryEditorOperation*) (GeometryEditor.cpp:117)
==19845==    by 0xF212273:
geos::geom::util::GeometryEditor::edit(geos::geom::Geometry const*,
geos::geom::util::GeometryEditorOperation*) (GeometryEditor.cpp:88)
==19845==    by 0xBFB30FE:
geoc::alg::VertexSnapper::snapVertices(geoc::geo::GEOCGeom*,
geos::geom::CoordinateSequence*) (in
/host/Users/Tereza/Documents/CVUT-FSv/BP/src/geoc_cpp/libgeoc.so.1.0.0)
==19845==    by 0xBFB33A1: geoc::alg::VertexSnapper::snap() (in
/host/Users/Tereza/Documents/CVUT-FSv/BP/src/geoc_cpp/libgeoc.so.1.0.0)
==19845==    by 0x566782E: QgsConflateProvider::vertexSnap() (in
/host/Users/Tereza/Documents/CVUT-FSv/BP/src/qgsconflate/libqgsconflate.so.1.0.0)
==19845==    by 0x401C65: main (main.cpp:85)

==19845== 192 bytes in 3 blocks are possibly lost in loss record 347 of 426
==19845==    at 0x4C2C154: operator new(unsigned long)
(vg_replace_malloc.c:298)
==19845==    by 0xF206ACA:
geos::geom::GeometryFactory::createPolygon(geos::geom::LinearRing*,
std::vector<geos::geom::Geometry*, std::allocator<geos::geom::Geometry*>
==19845==    by 0xF212568:
geos::geom::util::GeometryEditor::editPolygon(geos::geom::Polygon const*,
geos::geom::util::GeometryEditorOperation*) (GeometryEditor.cpp:144)
==19845==    by 0xF212273:
geos::geom::util::GeometryEditor::edit(geos::geom::Geometry const*,
geos::geom::util::GeometryEditorOperation*) (GeometryEditor.cpp:88)
==19845==    by 0xBFB30FE:
geoc::alg::VertexSnapper::snapVertices(geoc::geo::GEOCGeom*,
geos::geom::CoordinateSequence*) (in
/host/Users/Tereza/Documents/CVUT-FSv/BP/src/geoc_cpp/libgeoc.so.1.0.0)
==19845==    by 0xBFB33A1: geoc::alg::VertexSnapper::snap() (in
/host/Users/Tereza/Documents/CVUT-FSv/BP/src/geoc_cpp/libgeoc.so.1.0.0)
==19845==    by 0x566782E: QgsConflateProvider::vertexSnap() (in
/host/Users/Tereza/Documents/CVUT-FSv/BP/src/qgsconflate/libqgsconflate.so.1.0.0)
==19845==    by 0x401C65: main (main.cpp:85)


==19845== 408 bytes in 3 blocks are possibly lost in loss record 382 of 426
==19845==    at 0x4C2C154: operator new(unsigned long)
(vg_replace_malloc.c:298)
==19845==    by 0xF1FABE5:
geos::geom::CoordinateArraySequence::CoordinateArraySequence(geos::geom::CoordinateArraySequence
const&) (new_allocator.h:92)
==19845==    by 0xF1FACD8: geos::geom::CoordinateArraySequence::clone()
const (CoordinateArraySequence.cpp:77)
==19845==    by 0xBFB7B6C:
geoc::edit::VertexGeometryEditorOperation::edit(geos::geom::CoordinateSequence
const*, geos::geom::Geometry const*) (in
/host/Users/Tereza/Documents/CVUT-FSv/BP/src/geoc_cpp/libgeoc.so.1.0.0)
==19845==    by 0xF211A26:
geos::geom::util::CoordinateOperation::edit(geos::geom::Geometry const*,
geos::geom::GeometryFactory const*) (CoordinateOperation.cpp:36)
==19845==    by 0xF2123D6:
geos::geom::util::GeometryEditor::editPolygon(geos::geom::Polygon const*,
geos::geom::util::GeometryEditorOperation*) (GeometryEditor.cpp:117)
==19845==    by 0xF212273:
geos::geom::util::GeometryEditor::edit(geos::geom::Geometry const*,
geos::geom::util::GeometryEditorOperation*) (GeometryEditor.cpp:88)
==19845==    by 0xBFB30FE:
geoc::alg::VertexSnapper::snapVertices(geoc::geo::GEOCGeom*,
geos::geom::CoordinateSequence*) (in
/host/Users/Tereza/Documents/CVUT-FSv/BP/src/geoc_cpp/libgeoc.so.1.0.0)
==19845==    by 0xBFB33A1: geoc::alg::VertexSnapper::snap() (in
/host/Users/Tereza/Documents/CVUT-FSv/BP/src/geoc_cpp/libgeoc.so.1.0.0)
==19845==    by 0x566782E: QgsConflateProvider::vertexSnap() (in
/host/Users/Tereza/Documents/CVUT-FSv/BP/src/qgsconflate/libqgsconflate.so.1.0.0)
==19845==    by 0x401C65: main (main.cpp:85)

...

Anybody knows how to fix that?

Thanks,

Tereza
_______________________________________________
geos-devel mailing list
geos-devel< at >lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel

Re: [GEOS] #501: Snap operation: wrong snapping

GEOS — 2013-04-30T20:15:03

#501: Snap operation: wrong snapping
------------------------+---------------------------------------------------
 Reporter:  aperi2007   |       Owner:  geos-devel< at >…              
     Type:  defect      |      Status:  new                       
 Priority:  major       |   Milestone:  GEOS Future               
Component:  Default     |     Version:  svn-trunk                 
 Severity:  Unassigned  |    Keywords:  jtsfail                   
------------------------+---------------------------------------------------

Comment(by strk):

 #629 is the ticket to implement closest snap point

Re: [GEOS] #629: Improve the snap algorithm choosing the closest_point as snapped vertex

GEOS — 2013-04-30T20:14:31

#629: Improve the snap algorithm choosing the closest_point as snapped vertex
-------------------------+--------------------------------------------------
 Reporter:  aperi2007    |       Owner:  geos-devel< at >…              
     Type:  enhancement  |      Status:  new                       
 Priority:  major        |   Milestone:                            
Component:  Default      |     Version:  svn-trunk                 
 Severity:  Unassigned   |    Keywords:                            
-------------------------+--------------------------------------------------

Comment(by strk):

 see #501 for one case that would be fixed by snapping to closest point

[GEOS] #629: Improve the snap algorithm choosing the closest_point as snapped vertex

GEOS — 2013-04-30T19:26:05

#629: Improve the snap algorithm choosing the closest_point as snapped vertex
-------------------------+--------------------------------------------------
 Reporter:  aperi2007    |       Owner:  geos-devel< at >…              
     Type:  enhancement  |      Status:  new                       
 Priority:  major        |   Milestone:                            
Component:  Default      |     Version:  svn-trunk                 
 Severity:  Unassigned   |    Keywords:                            
-------------------------+--------------------------------------------------
 Actually the snap algorithm choose as snap point the first vertex that
 match the rules (under to snap value) calling it "first snappable point".
 This could cause invalid polygon when there is more than one vertex under
 the limit snap value.
 To avoid this kind of invalidity an improve to the algorithm could be to
 snap the closest_point instead of the first snappable point.

 Find the closest_point if a time consuming analyze because should be
 necessary to analyze all the vertex of the geometry.
 But realistic many cases are resolvable checking a more limited number of
 vertex after the the analyzing vertex as example checking 10 or 20 vertex
 after the first snappable point to see if exists a more closest point.

GSoC 2013 Project Proposal

vishal tiwari — 2013-04-29T13:40:30

Hey,
I have submitted my GSoC proposal for the project: "Adding Voronoi Diagrams
to GEOS" , here:
https://google-melange.appspot.com/gsoc/proposal/review/google/gsoc2013/vishal_tiwari/13001

Feedback and suggestions are most welcome.

Thanks and kind Regards,

Re: Gsoc 2013

vishal tiwari — 2013-04-27T18:34:14

Hey!
I have submitted my GSoC Proposal for the project "Adding Voronoi Diagrams
to GEOS" here:
http://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/vishal_tiwari/13001

kindly review it and give me feedback so that i can further improve it
before the application deadline.
Thanks,
Vishal Tiwari

On 10 April 2013 15:38, Sandro Santilli <strk< at >keybit.net> wrote:

Re: Problem with convex hull generating bad polygons (I think)

Martin Davis — 2013-04-17T15:05:52

Yes, you do need to explicitly check validity - the WKT reader does not 
enforce validity.  This is because:
(a) validity checking is expensive, and may not always be needed
(b) some use cases require reading the geometry regardless of whether it 
is valid

This is a general principle with JTS/GEOS, by the way.  Geometries 
created manually or by external input must be checked for validity and 
then handled appropriately - the library methods do not do this 
automatically.  However, you can assume that any geometry created by 
library operations is valid.

On 4/16/2013 11:23 PM, Richard Frith-Macdonald wrote:

Re: Problem with convex hull generating bad polygons(I think)

Richard Frith-Macdonald — 2013-04-17T06:23:41

On 17 Apr 2013, at 06:45, Martin Davis wrote:


Thanks ... that confirms my suspicion that I must somehow be getting bad inputs ... I'm now doing the tedious work of adding calls to GEOSisValid() for all input sources and before/after various operatiosn in my code, to track down were the invalid geometry is coming from.   Almost all input in my code comes is handled via the WKT reader, and I had assumed that this would produce a nul geometry if the input text didn't contain a valid geometry, but it seems this may not be the case, and I need to check validity of the geometry explicitly after parsing the WKT.

Re: Problem with convex hull generating bad polygons (I think)

Martin Davis — 2013-04-17T05:45:21

ConvexHull does not require validity of the input - it only operates on 
the raw vertices of the input.  And it should always produce a valid 
output (which will be a polygon in the case of three or more 
non-collinear points).

Could the TopologyException come from the Union operation, not the 
ConvexHull?  Union definitely *does* require valid inputs, and if the 
inputs are not valid it almost always throws a TopologyException.



On 4/16/2013 11:53 AM, Richard Frith-Macdonald wrote:

Problem with convex hull generating bad polygons (Ithink)

Richard Frith-Macdonald — 2013-04-16T18:53:28

Sorry, this is not really a developer question, but I don't know where else to ask.
I might be encountering a bug, but most likely I'm just misunderstanding and doing something wrong.

I have code which is failing with 'TopologyException:side location conflict at' errors when performing a convex hull operation using the C API.
Adding diagnostics to print the WKT of things before the operation, it looks like I'm feeding in an invalid polygon (one with repeated points), but I don't know why.
My code starts (as far as I can tell) with valid simple (ie no inner rings) polygons, and attempts top merge/extend some of them as follows:

In some cases, I want one polygon to be extended to include another ... I do a union of the two and then a convex hull of the result, using this to replace the original polygon.
In other cases, I want one polygon to be extended to touch another ... I calculate the nearest points on the two polygons and then union the first polygon with the closest point of the second polygon, and do a convex hull of the union, using it to replace the first polygon.

I think one of these operations must be producing an invalid polygon as its output, and then that is causing the topology exception later on when the output of one pass is used as input in a later pass.

So, my guess is I'm doing something stupid here ... should the convex hull operation always produce a valid polygon as output?
Is a union of two polygons not valid as input for convex hull?
Is a union of a polygon and a point not valid for input for convex hull?

Thanks in advance for any help.

Re: Compiling GEOS 64-bit

Crispin Cooper — 2013-04-11T15:41:14

Solved this, thanks.  For the benefit of anyone reading the list 
archives, from the command prompt I had to run

autogen.bat
"C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\Vcvarsall.bat" amd64

And then the usual build instruction worked fine

nmake /f makefile.vc MSVC_VER=1500

A few warnings existed about size_t being condensed to ulong.  Not a 
problem for my purposes.

Best,

Crispin