Opened 14 years ago

Last modified 3 years ago

#344 assigned defect

Out of memory on multiline buffer [JTS fails too]

Reported by: sberna Owned by: strk
Priority: major Milestone: Upstream
Component: Default Version: main
Severity: Significant Keywords: buffer jtsfail
Cc:

Description

After applying a buffer of 0.005 to the attached geometry in hex wkb the library starts growing in memory usage until the kernel kills it. It never returns the buffered geometry nor any error message.

Attachments (2)

fail_geom.txt.gz (92.9 KB ) - added by sberna 14 years ago.
txt file containing the wkb multiline geometry in ascii hex
roads_broken_geom.txt.gz (120.0 KB ) - added by sberna 14 years ago.
Another geometry that crashes the library

Download all attachments as: .zip

Change History (21)

by sberna, 14 years ago

Attachment: fail_geom.txt.gz added

txt file containing the wkb multiline geometry in ascii hex

by sberna, 14 years ago

Attachment: roads_broken_geom.txt.gz added

Another geometry that crashes the library

comment:1 by sberna, 14 years ago

Both geometries are reported as valid by the library.

in reply to:  1 ; comment:2 by strk, 14 years ago

Replying to sberna:

Both geometries are reported as valid by the library.

Note that GEOS-3.2.1 contains a fix for a bug giving false positives for ValidOp.

in reply to:  2 comment:3 by sberna, 14 years ago

Replying to strk:

Replying to sberna:

Both geometries are reported as valid by the library.

Note that GEOS-3.2.1 contains a fix for a bug giving false positives for ValidOp.

Downloaded GEOS-3.2.2 to test both geometries, and no changes. Both geometries are reported as valid and the buffer operation crashes.

comment:4 by strk, 14 years ago

wow, I confirm the huge memory use. I've added an XML tester with your geometry in tests/xmltester/tests/bug334.xml Will take a look when i find some time.

comment:5 by strk, 14 years ago

Milestone: 3.3.0
Owner: changed from geos-devel@… to strk
Status: newassigned

comment:6 by strk, 14 years ago

Severity: UnassignedSignificant

Note that the correct name of the file is tests/xmltester/tests/bug344.xml (fixed in 3093)

comment:7 by strk, 13 years ago

Version: 3.2.0svn-trunk

JTS-1.12 has the same exact problem:

jts$ build/dist/bin/testrunner.sh -files /usr/src/geos/geos/tests/xmltester/tests/bug344.xml
=====  Test Runner  -  JTS Topology Suite (Version 1.12.0)  =====
Reading test file /usr/src/geos/geos/tests/xmltester/tests/bug344.xml
Running tests...
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
        at com.vividsolutions.jts.noding.SegmentNodeList.createSplitEdge(SegmentNodeList.java:245)

comment:8 by strk, 13 years ago

Summary: After applying a buffer over a multiline the library starts growing in memory usage and hungsOut of memory on multiline buffer [JTS fails too]

comment:9 by strk, 13 years ago

Milestone: 3.3.0GEOS Future

we'll have to wait for this to be fixed at the JTS side

comment:10 by strk, 13 years ago

Keywords: buffer added

comment:11 by strk, 12 years ago

Keywords: jtsfail added

See also #502 and #383 for more cases.

comment:12 by strk, 10 years ago

I found another case of this. In common with this case the input is a MULTILINESTRING composed by many components. 101 components in my case, 3272 elements in _this_ case.

I guess the amount of components makes a lot more endcaps than need to be noded. Any news on the JTS side Martin ?

comment:13 by strk, 10 years ago

For comparison: computing the union of the buffer of each component is extremely faster and less ram-consuming. The results are the same.

I'm talking about 200 milliseconds vs 6000 ms. Sounds like a possible way to handle it internally.

comment:14 by strk, 10 years ago

Another two observations: using flat caps reduces the time and memory; linemerging the input before passing to buffer reduces time and memory.

comment:15 by strk, 10 years ago

Interesting statistic: the version of input dataset being a multilinestring of 101 segments results in OffsetCurveSetBuilder getting 101 curves and noding of those curves resulting in 527535 edges !

I fail to understand the math behind this correlation.

comment:16 by strk, 10 years ago

One note: the geometry in the attached case fails with original precision

bufferOriginalPrecision failed (TopologyException: depth mismatch at at -71.398537387920598 -33.039255295419302), trying with reduced precision

The input is valid, according to IsValidOp

comment:17 by strk, 10 years ago

See #693 for another reproducible example and some more comments

comment:18 by robe, 6 years ago

Milestone: GEOS FutureGEOS Fund Me

Milestone renamed

comment:19 by pramsey, 3 years ago

Milestone: GEOS Fund MeUpstream
Note: See TracTickets for help on using tickets.