Bug report #4088
Freeze while rendering labels (master 17e864b)
|Affected QGIS version:||Regression?:||No|
|Operating System:||Easy fix?:||No|
|Pull Request or Patch supplied:||No||Resolution:||fixed|
|Crashes QGIS or corrupts data:||Copied to github as #:||14071|
While testing the fix for bug #4083 I got a qgis freeze.
Opened the city_data.qgs project file (created with https://github.com/strk/qgis_pgis_topoview for the city_data topology created by [postgis_src]/topology/test/load_topology.sql).
Last few lines on console are:
Debug: /usr/src/qgis/qgis/src/core/qgsmaprenderer.cpp: 371: (render) Input extent: 3.0000000000000000,-4.0000000000000000 : 63.0000000000000000,45.0000000000000000
Debug: /usr/src/qgis/qgis/src/core/qgsmaplayer.cpp: 924: (setCacheImage) cache Image set!
Debug: /usr/src/qgis/qgis/src/core/qgsvectorlayer.cpp: 957: (draw) rendering v2:
Debug: /usr/src/qgis/qgis/src/core/qgsvectorlayer.cpp: 974: (draw) attrs: edge_id - 0
Debug: /usr/src/qgis/qgis/src/providers/postgres/qgspostgresprovider.cpp: 3433: (openCursor) Starting read-only transaction
Debug: /usr/src/qgis/qgis/src/core/qgspallabeling.cpp: 606: (registerFeature) Ignoring feature 30 due PAL exception: Geometry Type is unknow
#3 Updated by Martin Dobias almost 9 years ago
- File bug4088fix.diff added
That sounds like a mutex not unlocked when PAL exception is thrown. I have prepared a small patch, though I am not at my dev machine now so I cannot compile/test it.
Most likely problem happens when a geometry collection is passed to labeling engine. The newly added clipping in #4083 might be the cause - the intersection operation between extent rectangle and input feature may result in geometry collection, right?
#5 Updated by Sandro Santilli almost 9 years ago
Intersections made with GEOS can result in collections.
They can also result in crashes so I'd be very careful about using them for
labeling purposes. If there's a way to avoid changing the input but only the way
it's considered it should be favored (ie: only consider segments intersecting the viewport rather than all of them?).
Btw, it would be helpful if the message showed also the geometry type id beside the 'unknow' label (there's a typo too)
#6 Updated by Martin Dobias almost 9 years ago
- Status changed from Open to Closed
- Resolution set to fixed
- Pull Request or Patch supplied set to No
Bugfix applied in 8e08c53
Regarding the intersections with GEOS: is there a high chance of a crash? Are there still robustness problems?
If we were going to use the whole segments that intersect the viewport we would still have to calculate the intersection of segments with the viewport in order to place label candidates only to visible positions. So I guess a better solution is to run intersect on the whole geometry.
#7 Updated by Sandro Santilli almost 9 years ago
I wouldn't say "high" chances, but there still are. Maybe you could catch and let go if it happens. I don't really have statistical data about robustness issues happening with rectangular intersections (should be handled in a special way, faster).
Doesn't the memory representation you're using (the Qt one) support clipping ?
#8 Updated by Martin Dobias almost 9 years ago
The memory representation for labeling is a custom one introduced by the PAL labeling library: geometries are input as GEOS geometry instances and then converted to that representation.
Anyway Qt is able to do clipping, but that is limited to rendering (and not exposed to public API) and seems to be slow.
Additionally QGIS has its own line and polygon clipping routines, but for yet another representation (using QPolygonF from Qt). Ultimately this may be the fastest and safest solution, however it would require us to make QgsClipper class more generic.