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)
Change History (21)
by , 14 years ago
| Attachment: | fail_geom.txt.gz added |
|---|
by , 14 years ago
| Attachment: | roads_broken_geom.txt.gz added |
|---|
Another geometry that crashes the library
follow-up: 3 comment:2 by , 14 years ago
comment:3 by , 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 , 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 , 14 years ago
| Milestone: | → 3.3.0 |
|---|---|
| Owner: | changed from to |
| Status: | new → assigned |
comment:6 by , 13 years ago
| Severity: | Unassigned → Significant |
|---|
Note that the correct name of the file is tests/xmltester/tests/bug344.xml (fixed in 3093)
comment:7 by , 13 years ago
| Version: | 3.2.0 → svn-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 , 13 years ago
| Summary: | After applying a buffer over a multiline the library starts growing in memory usage and hungs → Out of memory on multiline buffer [JTS fails too] |
|---|
comment:9 by , 13 years ago
| Milestone: | 3.3.0 → GEOS Future |
|---|
we'll have to wait for this to be fixed at the JTS side
comment:10 by , 12 years ago
| Keywords: | buffer added |
|---|
comment:12 by , 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 , 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 , 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 , 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 , 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:19 by , 3 years ago
| Milestone: | GEOS Fund Me → Upstream |
|---|
txt file containing the wkb multiline geometry in ascii hex