Re: [GEOS] #227: Deleting 'void*' is undefined in IntervalRTreeLeafNode class.

#227: Deleting 'void*' is undefined in IntervalRTreeLeafNode class.
-------------------------+--------------------------------------------------
 Reporter:  mloskot      |        Owner:  geos-devel <at> lists.osgeo.org
     Type:  defect       |       Status:  new                       
 Priority:  major        |    Milestone:  3.2.0                     
Component:  Core         |      Version:  svn-trunk                 
 Severity:  Significant  |   Resolution:                            
 Keywords:  void         |  
-------------------------+--------------------------------------------------
Changes (by pramsey):

  * milestone:  => 3.2.0

-- 
Ticket URL: <http://trac.osgeo.org/geos/ticket/227#comment:2>
GEOS <http://geos.refractions.net/>
GEOS (Geometry Engine - Open Source) is a C++ port of the Java Topology Suite (JTS).

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

Re: [GEOS] #232: Static string in WKBReader causes glibc errors when Geos is statically linked

#232: Static string in WKBReader causes glibc errors when Geos is statically
linked
------------------------+---------------------------------------------------
 Reporter:  yvesdaemen  |        Owner:  geos-devel <at> lists.osgeo.org
     Type:  defect      |       Status:  new                       
 Priority:  major       |    Milestone:  3.0.4                     
Component:  Default     |      Version:  3.0.3                     
 Severity:  Unassigned  |   Resolution:                            
 Keywords:              |  
------------------------+---------------------------------------------------
Changes (by pramsey):

  * milestone:  3.1.0 => 3.0.4

-- 
Ticket URL: <http://trac.osgeo.org/geos/ticket/232#comment:3>
GEOS <http://geos.refractions.net/>
GEOS (Geometry Engine - Open Source) is a C++ port of the Java Topology Suite (JTS).

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

Re: Segmentation Fault in ARM platform

Paul and Frank, thank you for your time.
I made some tests here and, with a simple example and some time expent, 
I could realize the problem was not with geos. I wote an example to read 
a shapefile, get it's "center point" and iterate each feature to check 
if it "Contains(centerPoint)".
Compiling this test "alone", inside a simple main.cpp it works, but the 
same main.cpp linked with my hole program it fails (seg fault).
So, maybe the problem is not the platform, but a library conflict, or a 
bug in my program. I'll try to find it and so I tell you.

Thank you again and best regards.

Adriano

Frank Warmerdam escreveu:
> Paul Ramsey wrote:
>> You're going to want to find someone who can re-produce this, which
>> means someone with a big-endian platform. Perhaps Frank can on his old
>> iBook. Note that you are transferring WKB from OGR to GEOS, so the
>> problem could be the writing step in OGR (writing something invalid)
>> or the reading step in GEOS (screwing up). Attach your program to an
>> issue in trac.
>
> Paul,
>
> As I understand it the ARM is being used in "middle endian"
> mode, or at least is not a traditional big endian system so I
> don't believe my iBook will produce the same problem.
>
> I'm personally not too keen on making all my software support this

[GEOS] #234: Intersection Crashes On Multipolygons With Empty Holes

#234: Intersection Crashes On Multipolygons With Empty Holes
------------------------+---------------------------------------------------
 Reporter:  slambright  |       Owner:  geos-devel <at> lists.osgeo.org
     Type:  defect      |      Status:  new                       
 Priority:  major       |   Milestone:  3.1.0                     
Component:  Default     |     Version:  3.0.3                     
 Severity:  Unassigned  |    Keywords:                            
------------------------+---------------------------------------------------
 When doing operations to complicated multipolygons, I ran across this.
 When I had a multipolygon of the form:
 MULTIPOLYGON (((1.0000000000000000 1.0000000000000000, 1.0000000000000000
 5.0000000000000000, 5.0000000000000000 5.0000000000000000,
 5.0000000000000000 1.0000000000000000, 1.0000000000000000
 1.0000000000000000), EMPTY))
 (empty, but existing, holes polygon)

 and I tried to intersect it with another polygon, say
 MULTIPOLYGON (((3.0000000000000000 3.0000000000000000, 3.0000000000000000
 4.0000000000000000, 4.0000000000000000 4.0000000000000000,
 4.0000000000000000 3.0000000000000000, 3.0000000000000000
 3.0000000000000000)))

 I get the error:
 CoordinateArraySequence.cpp:105: virtual const geos::geom::Coordinate&
 geos::geom::CoordinateArraySequence::getAt(size_t) const: Assertion
 `pos<vect->size()' failed.
 Abort

 However, if there isn't an empty hole polygon it works fine.

Re: [GEOS] #234: Intersection Crashes On Multipolygons With Empty Holes

This is an error in JTS as well.  EMPTY components are generally not 
handled.

The whole idea of having empty components seems pretty pointless to me 
anyway.  I suppose the best thing to do is to simply strip them out in 
geometry operations.

GEOS wrote:
> #234: Intersection Crashes On Multipolygons With Empty Holes
> ------------------------+---------------------------------------------------
>  Reporter:  slambright  |       Owner:  geos-devel <at> lists.osgeo.org
>      Type:  defect      |      Status:  new                       
>  Priority:  major       |   Milestone:  3.1.0                     
> Component:  Default     |     Version:  3.0.3                     
>  Severity:  Unassigned  |    Keywords:                            
> ------------------------+---------------------------------------------------
>  When doing operations to complicated multipolygons, I ran across this.
>  When I had a multipolygon of the form:
>  MULTIPOLYGON (((1.0000000000000000 1.0000000000000000, 1.0000000000000000
>  5.0000000000000000, 5.0000000000000000 5.0000000000000000,
>  5.0000000000000000 1.0000000000000000, 1.0000000000000000
>  1.0000000000000000), EMPTY))
>  (empty, but existing, holes polygon)
>
>  and I tried to intersect it with another polygon, say
>  MULTIPOLYGON (((3.0000000000000000 3.0000000000000000, 3.0000000000000000
>  4.0000000000000000, 4.0000000000000000 4.0000000000000000,
>  4.0000000000000000 3.0000000000000000, 3.0000000000000000
>  3.0000000000000000)))
>

CPU buildup with repeated operations

Hi, am having a problem with a system built using GEOS, wondering if anyone
could help. Am using GEOS to generate sound and graphics from geom
operations in realtime. If I do a constant amount of work (e.g. roughly 150
binary operations per second)  then gradually my CPU usage builds up, until
after about 5 minutes, it becomes unusable. This is whilst carrying out the
same amount of operations. 

Am using the C API on an Intel Core 2, can anyone think what this might be?
As far as I'm aware I'm destroying all objects after each set of operations,
but if I've missed one (and therefore have a constantly increasing number of
objects), does GEOS perform any housekeeping on created objects which could
cause this CPU buildup? The other thing I've considered is could it be an
Intel denormalization issue? 

Any ideas I'd be really grateful.... Theo

--

-- 
View this message in context: http://n2.nabble.com/CPU-buildup-with-repeated-operations-tp2440217p2440217.html
Sent from the GEOS Developers mailing list archive at Nabble.com.

Re: CPU buildup with repeated operations

thep wrote:
> Hi, am having a problem with a system built using GEOS, wondering if anyone
> could help. Am using GEOS to generate sound and graphics from geom
> operations in realtime. If I do a constant amount of work (e.g. roughly 150
> binary operations per second)  then gradually my CPU usage builds up, until
> after about 5 minutes, it becomes unusable. This is whilst carrying out the
> same amount of operations. 
> Am using the C API on an Intel Core 2, can anyone think what this might be?

What is memory usage? Does it increase significantly?
Chances are that if your program uses a lot of memory
then your system starts swapping, what uses CPU time quite a lot too.

> As far as I'm aware I'm destroying all objects after each set of operations,
> but if I've missed one (and therefore have a constantly increasing number of
> objects), does GEOS perform any housekeeping on created objects which could
> cause this CPU buildup?

I'd suggest to check if your program does proper cleanup, run it through
valgrind and check for memory leaks.

> The other thing I've considered is could it be an
> Intel denormalization issue? 

I'm not sure about that, but AFAIK this problem applies only to P4 and
prior CPUs from Intel CPUs. But you are using their successors actually.

Anyway, you may want to confirm this in Intel docs.

Best regards,

Re: [GEOS] #234: Intersection Crashes On Multipolygons With Empty Holes

#234: Intersection Crashes On Multipolygons With Empty Holes
----------------------------+-----------------------------------------------
 Reporter:  slambright      |        Owner:  geos-devel <at> lists.osgeo.org
     Type:  defect          |       Status:  new                       
 Priority:  minor           |    Milestone:                            
Component:  Core            |      Version:  3.0.3                     
 Severity:  Annoyance       |   Resolution:                            
 Keywords:  empty,geometry  |  
----------------------------+-----------------------------------------------
Changes (by mloskot):

  * priority:  major => minor
  * keywords:  => empty,geometry
  * component:  Default => Core
  * severity:  Unassigned => Annoyance
  * milestone:  3.1.0 =>

Comment:

 I've taken the liberty to paste Martin's
 [http://lists.osgeo.org/pipermail/geos-devel/2009-March/003950.html

 comment posted on the list]:

  ''This is an error in JTS as well.  EMPTY components are generally not
 handled. The whole idea of having empty components seems pretty pointless
 to me anyway. I suppose the best thing to do is to simply strip them out
 in geometry operations.''

 I believe we can leave the ticket open to not to forget in future, but
 with clear statement that users are advised to strip EMPTY components out

Re: CPU buildup with repeated operations

Hi, thanks for your response & ruling out denormalization. My program does
have a tiny memory leak, but it isn't necessarily within this code, and the
relative memory usage hardly increases after the CPU usage starts
increasing, so I don't think there's much swapping going on...

If it's not a memory issue, is there any possibility of non-destroyed
created objects taking up cpu time, even if I'm not doing any operations on
them?

Thanks,
Theo

Mateusz Loskot wrote:
> 
> thep wrote:
>> Hi, am having a problem with a system built using GEOS, wondering if
>> anyone
>> could help. Am using GEOS to generate sound and graphics from geom
>> operations in realtime. If I do a constant amount of work (e.g. roughly
>> 150
>> binary operations per second)  then gradually my CPU usage builds up,
>> until
>> after about 5 minutes, it becomes unusable. This is whilst carrying out
>> the
>> same amount of operations. 
>> Am using the C API on an Intel Core 2, can anyone think what this might
>> be?
> 
> What is memory usage? Does it increase significantly?

Re: CPU buildup with repeated operations

thep wrote:
> Hi, thanks for your response & ruling out denormalization. My program does
> have a tiny memory leak, but it isn't necessarily within this code, and the
> relative memory usage hardly increases after the CPU usage starts
> increasing, so I don't think there's much swapping going on...

OK

> If it's not a memory issue, is there any possibility of non-destroyed
> created objects taking up cpu time, even if I'm not doing any operations on
> them?

I'd try to identify thread running in your app process.
GEOS does not run any threads behind the scene so if you don't execute
GEOS nothing is being executed implicitly.

Best regards,
--

-- 
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org