Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

High memory usage with Snap geometries to layer and "exception:unknown" message #27264

Closed
qgib opened this issue Jul 17, 2018 · 7 comments
Closed
Labels
Bug Either a bug report, or a bug fix. Let's hope for the latter! Processing Relating to QGIS Processing framework or individual Processing algorithms

Comments

@qgib
Copy link
Contributor

qgib commented Jul 17, 2018

Author Name: Antoine Lafranchis (@alafr)
Original Redmine Issue: 19436
Affected QGIS version: 3.7(master)
Redmine category:digitising


In some circumstances, the computer freezes with 99.9% memory usage (then task manager stops responding...) when using the algorithm 'Snap geometries to layer'.
It apparently happens only when snapping a line layer to a point reference layer, with a small tolerance (0.00001 or lower).
It happend initially on a huge shapefile with geometry errors, but then I could reproduce it with tempopary layers: a line layer with a single line and a point layer with 3 points: the 1st point was precisely on a vertex, the 2nd point close to a second vertex (within the tolerance radius) and the 3rd point quite far from the line.

Because I had to "brutally" shut down and restart the computer, I don't have any test file to attach and no crash log. The only details that were left were the processing history: ```processing.run("qgis:snapgeometries", {'INPUT':'Point?crs=EPSG:4326&uid={50146ea0-3a7a-4515-8241-e842f2ef1717}','REFERENCE_LAYER':'LineString?crs=EPSG:4326&uid={c6586332-d416-495e-868d-e34430dab439}','TOLERANCE':1e-5,'BEHAVIOR':0,'OUTPUT':'memory:'})


---

- [test_project.qgz](https://issues.qgis.org/attachments/download/14412/test_project.qgz) (Antoine Lafranchis)
- [test_memory_usage.png](https://issues.qgis.org/attachments/download/14413/test_memory_usage.png) (Antoine Lafranchis)
- [QGIS.zip](https://issues.qgis.org/attachments/download/14425/QGIS.zip) (Antoine Lafranchis)
- [test_snap_config.png](https://issues.qgis.org/attachments/download/14426/test_snap_config.png) (Antoine Lafranchis)
- [qgis_version.png](https://issues.qgis.org/attachments/download/14427/qgis_version.png) (Antoine Lafranchis)
- [qgis_snap_exception.png](https://issues.qgis.org/attachments/download/14428/qgis_snap_exception.png) (Antoine Lafranchis)
@qgib
Copy link
Contributor Author

qgib commented Jul 20, 2018

Author Name: Nyall Dawson (@nyalldawson)


Duplicate of #26385


  • status_id was changed from Open to Closed
  • resolution was changed from to duplicate

@qgib
Copy link
Contributor Author

qgib commented Feb 23, 2019

Author Name: Antoine Lafranchis (@alafr)


I still experience abnormally high memory usage and Qgis freezing when snapping points to lines with small tolerance.
This time i ended qgis-dev from the task manager without waiting for the probable crash so that i could send this update.
Memory usage was at 2.5 GB and continuously increasing. The 2 shapefiles contain only 6 features in total.
It's apparently not a duplicate of #26385 which is fixed.


  • 14412 was configured as test_project.qgz
  • 14425 was configured as QGIS.zip
  • 14426 was configured as test_snap_config.png
  • 14413 was configured as test_memory_usage.png
  • status_id was changed from Closed to Reopened

@qgib
Copy link
Contributor Author

qgib commented Feb 23, 2019

Author Name: Giovanni Manghi (@gioman)


Antoine Lafranchis wrote:

I still experience abnormally high memory usage and Qgis freezing when snapping points to lines with small tolerance.
This time i ended qgis-dev from the task manager without waiting for the probable crash so that i could send this update.
Memory usage was at 2.5 GB and continuously increasing. The 2 shapefiles contain only 6 features in total.
It's apparently not a duplicate of #26385 which is fixed.

sure have you tested a recent build?


  • resolution was changed from duplicate to
  • status_id was changed from Reopened to Feedback

@qgib
Copy link
Contributor Author

qgib commented Feb 23, 2019

Author Name: Antoine Lafranchis (@alafr)


I use build 4d5dad8.
I tried again to snap the same layers and waited. It didn't actually crash, memory usage peaked at 2.6 GB then dropped suddenly and displayed an "exception:unknown" message.


  • 14428 was configured as qgis_snap_exception.png
  • 14427 was configured as qgis_version.png

@qgib
Copy link
Contributor Author

qgib commented Feb 23, 2019

Author Name: Giovanni Manghi (@gioman)


  • category_id was changed from Processing/Core to Digitising
  • status_id was changed from Feedback to Open
  • priority_id was changed from High to Normal
  • version was changed from 3.2 to 3.7(master)
  • crashes_corrupts_data was changed from 1 to 0
  • subject was changed from Windows crash with Snap geometries to layer to High memory usage with Snap geometries to layer and "exception:unknown" message

@qgib qgib added Bug Either a bug report, or a bug fix. Let's hope for the latter! Digitizing Related to feature digitizing map tools or functionality labels May 25, 2019
@alexbruy alexbruy added Processing Relating to QGIS Processing framework or individual Processing algorithms and removed Digitizing Related to feature digitizing map tools or functionality labels Jan 18, 2020
@gioman
Copy link
Contributor

gioman commented Jun 26, 2021

test_snap_config.png (Antoine Lafranchis)

On the latest master, using such (unnecessary?) small tolerance, it (still) leaks memory eating up all of it and causing a system freeze.

@gacarrillor
Copy link
Member

gacarrillor commented Sep 6, 2021

This was solved by #44766

Please reopen if necessary.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Either a bug report, or a bug fix. Let's hope for the latter! Processing Relating to QGIS Processing framework or individual Processing algorithms
Projects
None yet
Development

No branches or pull requests

4 participants