Bug report #1427

GRASS vectors support: memory leak?

Added by Maciej Sieczka - almost 16 years ago. Updated about 15 years ago.

Status:Closed
Priority:Low
Assignee:nobody -
Category:GRASS
Affected QGIS version: Regression?:No
Operating System:Debian Easy fix?:No
Pull Request or Patch supplied: Resolution:fixed
Crashes QGIS or corrupts data: Copied to github as #:11487

Description

1. Add a fairly big GRASS vector. In my case with 2 GB RAM, 512 MB swap a 1,500,000 vertices map was enough.

2. Zoom, pan, query, change symbology etc - notice how your memory usage grows constantly. Finalyy you run out of memory and QGIS is killed by OS.

This doesn't take place with even circa 10x bigger Shapefiles.

Debian testing amd64, SVN trunk r9705.

History

#1 Updated by Frank Warmerdam - almost 16 years ago

Hi,

Has any effort been made to see if this is a QGIS or OGR problem?

ALso, particulars of the versions of OGR and grass libraries used would be helpful.

#2 Updated by Maciej Sieczka - almost 16 years ago

Replying to [comment:1 warmerdam]:

Hi,

Has any effort been made to see if this is a QGIS or OGR problem?

Good point. I don't know how to do it though.

ALso, particulars of the versions of OGR and grass libraries used would be helpful.

GRASS 6.4 SVN develbranch6 , GDAL SVN trunk 9e244e8f (SVN r15760). GDAL-GRASS plugin built from the specified GDAL version against the specified GRASS version.

#3 Updated by Frank Warmerdam - almost 16 years ago

One approach to testing if it is an OGR problem would be to run ogrinfo against a grass dataset under valgrind and examine what leaks show up in a leak report, if any.

Alternatively, writes a small program or script using OGR that repeatedly scans over a grass vector dataset and see if the memory of the process grows for each iteration.

It sounds like you are running against trunk of everything, so presumably this does represent a real and current leak at some level of the software stack.

#4 Updated by Martin Dobias almost 16 years ago

QGIS has its own implementation of GRASS vector layers, independent from OGR, so this issue is probably a QGIS problem (or GRASS problem).

#5 Updated by Frank Warmerdam - almost 16 years ago

Ah, my error. Sorry for the noise!

#6 Updated by Paolo Cavallini almost 16 years ago

  • Status changed from Open to Closed
  • Resolution set to worksforme

Please check if this still applies - I tested extensively, without problems.
If it still holds true, please reopen the ticket.
Thanks

#7 Updated by Maciej Sieczka - almost 16 years ago

  • Status changed from Closed to Feedback
  • Resolution deleted (worksforme)

Replying to [comment:6 pcav]:

Please check if this still applies - I tested extensively, without problems.
If it still holds true, please reopen the ticket.

Replying to [comment:3 pcav]:

Tested with spearfish, and it works. Please check whether it is a local problem on your
computer and reopen it if necessary.

The bug is still present. I don't see how it could be a problem with my machine. Can you elaborate?

The same dat as a GRASS vector map make QGIS allocate memory but not free it - I can make QGIS crash this way due to depleting all RAM and swap within minutes, only panning and zooming around. However, the same data as a Shapefile don't pose memory allocation problems to QGIS.

QGIS trunk , GDAL 1.6+SVN , GRASS 6.5 .

#8 Updated by Martin Dobias almost 16 years ago

  • Status changed from Feedback to Closed
  • Resolution set to fixed

I can replicate with a large grid layer that qgis slowly leaks memory.

Fixed in (trunk) and (branch 1.0)

#9 Updated by Anonymous about 15 years ago

Milestone Version 1.0.1 deleted

Also available in: Atom PDF