Bug report #14559

Memory Layer crashing in 2.14

Added by Jamie Portman almost 8 years ago. Updated almost 8 years ago.

Affected QGIS version:2.14.0 Regression?:No
Operating System: Easy fix?:No
Pull Request or Patch supplied:No Resolution:fixed/implemented
Crashes QGIS or corrupts data:Yes Copied to github as #:22532


I have numerous projects with Memory Layers used for labelling (using the Easy Custom Label Plugin)

Since starting to use v2.14, I regularly find that QGIS crashes with a minidump error when I try to edit the vertices (or move) the objects.
After much trial and error thismorning, I appear to have it narrowed down to the style being rule based by length (eg. $length <1000)
(objects less than a certain distance have no line, those longer do so that they appear as a callout).

As soon as I use the 'node tool' or 'move features' tool to edit the label location, I get a minidump error.
I have created a second identical memory layer (also done in v2.8) with the exception of style by length. It does not crash.
I have saved the memory layer as a shapefile and applied exactly the same styling to it, and it also behaves as expected with no crashing.

I have reopened the project in v2.8 and v2.10 with no crashing when trying to edit.

Has something changed in the length-calculation function that would cause this changed behaviour?
I have also tried changing the Ellipsoid for length measurements project settings - crashing occurs regardless of whether an ellipsoid (GRS80) or none (Planimetric) is selected.

I have attached a copy of a project with this behaviour happening.

MemoryLayer_Crashing.zip (29.5 KB) Jamie Portman, 2016-03-23 05:09 PM

Associated revisions

Revision 59d4b85c
Added by Nyall Dawson almost 8 years ago

Avoid some unnecessary detachments in memory provider

Should speed up the provider slightly and also refs #14559 (I can
no longer reproduce that crash with this change)

Revision fcbc61af
Added by Nyall Dawson almost 8 years ago

Fix crash in memory provider (fix #14559)

(cherry-picked from 59d4b85c73aff475429005f321d6009ade9fc8c6)


#1 Updated by Nyall Dawson almost 8 years ago

  • Status changed from Open to Feedback

Please retest with tomorrow's nightly version - this should be fixed now (at least, after the change I pushed I could no longer reproduce the crash)

#2 Updated by Jamie Portman almost 8 years ago

Thanks Nyall.
Apologies for the delay - had to test at home as we have secure system and can't install anything at work.
Seems to be fixed in the nightly build - 2.15.0 (nightly), but still present in the 2.14.1 (nightly) build.

Will this fix flow through to the eventual 2.14 LTR? Our IT department refuse to install anything but the LTR - so we're still a few months off being able to use 2.14 ( a few of us were allowed it for testing only).

#3 Updated by Nyall Dawson almost 8 years ago

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

Thanks for the confirmation. I'll backport this so it will be included in 2.14.2.

Also available in: Atom PDF