Bug report #10356
Buffer locks up system/fills swap (memory leak)
Status: | Closed | ||
---|---|---|---|
Priority: | Severe/Regression | ||
Assignee: | - | ||
Category: | Processing/QGIS | ||
Affected QGIS version: | master | Regression?: | |
Operating System: | Easy fix?: | ||
Pull Request or Patch supplied: | No | Resolution: | up/downstream |
Crashes QGIS or corrupts data: | No | Copied to github as #: | 18777 |
Description
the memory usage goes up very quickly and my system becomes very unresponsive after about 30 seconds.
processing does not complete even after a few hours.
offending shp file attached.
- segments: 5
- buffer distance: 0.013
- same thing happens with or without dissolve.
i'm using git master d652a8099fc5c234eeb3b19e754d91e001f2f956
QGIS version -------------- 2.3.0-Master QGIS code revision -------- d652a80 Compiled against Qt ------- 4.8.5 Running against Qt -------- 4.8.5 Compiled against GDAL/OGR - 1.10.1 Running against GDAL/OGR -- 1.10.1 Compiled against GEOS ----- 3.4.2-CAPI-1.8.2 Running against GEOS ------ 3.4.2-CAPI-1.8.2 r3921 PostgreSQL Client Version - 9.3.4 SpatiaLite Version -------- 3.0.1 QWT Version --------------- 5.2.3 PROJ.4 Version ------------ 480 QScintilla2 Version ------- 2.8 Python -------------------- 2.7.6
History
#1 Updated by Johannes Kroeger over 10 years ago
I tried this on a machine with more RAM than JH's. The process worked but ended up using about 7 Gigabytes for this operation. What is worse, it did not free this memory afterwards. I had to close QGIS to free it.
I loaded the shapefile. Vector -> Geoprocessing Tools -> Buffer. Left the segments at 5, set the distance to 0.013, set a filename to output and clicked OK.
QGIS version 2.3.0-Master
QGIS code revision acd574d
#2 Updated by Giovanni Manghi over 10 years ago
- Target version set to Version 2.4
- Operating System deleted (
linux) - Priority changed from Normal to Severe/Regression
- Subject changed from Buffer locks up system/fills swap to Buffer locks up system/fills swap (memory leak)
- File buffer.zip added
A few notes:
- the problem seems to be related to the "complexity" of the geometry, a slightly generalized version of the line allows the qgis buffer operation to run in a few seconds without issues.
- also GRASS v.buffer (run in the processing toolbox) seems to hang with the original geometry (but with no memory leak), but works with the simplified/generalized one
- SAGA buffer (run in the processing toolbox) produces a result in a few seconds using the original geometry as input
- older releases of QGIS (<= 2.0.1) didn't created an output with the original vector (the message at the end of the operation was that the result had an invalid geometry) but also didn't had the memory leak and didn't froze the program
#3 Updated by Martin Dobias over 10 years ago
- Resolution set to up/downstream
- Status changed from Open to Closed
The issue with high memory consumption / memory leaks lies inside of the GEOS library. I was able to create a test case that does not involve QGIS.
The input shape is not really small: it contains nearly 32 thousand vertices.
With smaller buffer width (e.g. 0.001) or greater width (e.g. 1.0) the memory consumption stays low.
#4 Updated by Martin Dobias over 10 years ago
Created GEOS bug report for the issue: http://trac.osgeo.org/geos/ticket/693
#5 Updated by Giovanni Manghi over 7 years ago
The "ftools" category is being removed from the tracker, changing the category of this ticket to "Processing/QGIS" to not leave the category orphaned.