Bug report #2714

Crash when resizing map window with Qt 4.6

Added by Marco Hugentobler over 9 years ago. Updated about 6 years ago.

Status:Closed
Priority:Normal
Assignee:-
Category:Map Canvas
Affected QGIS version:master Regression?:No
Operating System:All Easy fix?:No
Pull Request or Patch supplied:No Resolution:up-/downstream
Crashes QGIS or corrupts data:No Copied to github as #:12774

Description

Load a large vector file. Resize the main windows several time (or add the attribute table docked). Qgis crashes with Qt 4.6. With 4.5, there was no crash. Maybe this is because of concurrent vector access?

qgis_canvas_resize_point_bt - Resizing canvas with single point layer and render cache "on" (40.3 KB) marisn -, 2010-12-14 05:23 AM

qgis_canvas_resize_line_bt - Resizing canvas with single line layer and render cache "on" (33.7 KB) marisn -, 2010-12-14 05:24 AM

qgis_1_6_branch_resize_crash1.txt Magnifier - crash log (2.86 KB) Markus Neteler, 2011-03-02 05:57 AM

qgis_1_6_branch_resize_crash2.txt Magnifier - crash log (2.86 KB) Markus Neteler, 2011-03-02 05:57 AM

resize-crash-backtrace.txt Magnifier (5.1 KB) Radim Blazek, 2013-06-03 09:14 AM


Related issues

Related to QGIS Application - Bug report #3771: White stripes when panning map Closed 2011-07-25

History

#1 Updated by Martin Dobias over 9 years ago

It seems it's caused by the processEvents() calls in QgsVectorLayer - the crash happens in Qt libraries. If I comment out the processEvents() calls, the segfault is gone.

My GSoC project should handle this once the rendering will be completely done in worker thread(s), but that will be too late for 1.5. So probably we should just disable these calls (they are already disabled on OS X).

#2 Updated by Marco Hugentobler over 9 years ago

Looking forward for a clean solution with the worker thread.
For the short term (1.5), maybe it is possible to improve the protection for the render method?

Because disable the calls of processEvents would mean no incremental screen updates and no interruption of the rendering for 1.5? This would make handling of large datasets with QGIS very difficult.

#3 Updated by Jürgen Fischer over 9 years ago

Replying to [comment:2 mhugent]:

Because disable the calls of processEvents would mean no incremental screen updates and no interruption of the rendering for 1.5? This would make handling of large datasets with QGIS very difficult.

The WMS provider now has the same problem. It seems to be a bug in the new Qt Animation Framework as the Qt Bug report #6797 looks related.

Following change works around the problem:

Index: src/gui/qgsmapcanvas.cpp
===================================================================
--- src/gui/qgsmapcanvas.cpp    (revision 13491)
+++ src/gui/qgsmapcanvas.cpp    (working copy)
@@ -960,7 +960,11 @@
     updateCanvasItemPositions();

     updateScale();
+#if QT_VERSION >= 0x40600
+    QTimer::singleShot( 1, this, SLOT( refresh() ) );    // take rendering outside of resizeEvent()
+#else
     refresh();
+#endif
     emit extentsChanged();
   }
   isAlreadyIn = false;

#4 Updated by Jürgen Fischer over 9 years ago

I applied the workaround in f8b728bd (SVN r13501).

#5 Updated by Jürgen Fischer over 9 years ago

workaround fixes the crash.

#6 Updated by marisn - about 9 years ago

Replying to [comment:6 jef]:

workaround fixes the crash.

No. It doesn't. Can't get backtrace, as running under GDB frezes whole KDE and core is truncated.

Resizing window with present vector layer still results in segfault. Can be trigerred also by moving around toolbars (cause canvas resize). And this isn't "minor: annoyance"

QGIS trunk 13763

Qt 4.6.3

Gentoo ~AMD64

#7 Updated by marisn - almost 9 years ago

Issue dissapears when I disable "Use render caching" in Options. Also - to make QGIS crash, one needs to issue multiple redraws - resize layer TOC or window and not simply minimize/maximize it. Seems to be some race condition as next redraw has to start before previous is complete.

QGIS trunk 14908

Gentoo ~AMD64

x11-libs/qt-core-4.7.1-r1:4
x11-libs/qt-dbus-4.7.1:4
x11-libs/qt-gui-4.7.1-r1:4
x11-libs/qt-multimedia-4.7.1:4
x11-libs/qt-opengl-4.7.1:4
x11-libs/qt-qt3support-4.7.1:4
x11-libs/qt-script-4.7.1-r1:4
x11-libs/qt-sql-4.7.1:4
x11-libs/qt-svg-4.7.1:4
x11-libs/qt-test-4.7.1:4
x11-libs/qt-webkit-4.7.1-r1:4
x11-libs/qt-xmlpatterns-4.7.1:4
x11-libs/qtscriptgenerator-0.1.0:0

#8 Updated by Jürgen Fischer over 8 years ago

see also #2884.
a3cfe6fb (SVN r15506) might fix this.

#9 Updated by Jürgen Fischer over 8 years ago

Replying to [comment:11 jef]:

see also #2884.
a3cfe6fb (SVN r15506) might fix this.

185ec5db (SVN r15051) that is.

#10 Updated by Jürgen Fischer over 8 years ago

see also #2339

#11 Updated by adbosco - over 8 years ago

This looks a lot like the (possible) race condition that causes the crashes on changing symbology, reported on #3380, #3381 and #3391.

#12 Updated by Giovanni Manghi over 8 years ago

Replying to [comment:11 jef]:

see also #2884.
a3cfe6fb (SVN r15506) might fix this.

The crash when resizing the overview windows is indeed fixed. Unfortunately it seems that there is a secondary problem (let me know if you want me to open a new ticket): resizing the overview windows is very slow, with both the "cache rendering" enabled or disabled. Just tested it with a couple of polygon/line layers (shapes, wfs).

#13 Updated by Giovanni Manghi over 8 years ago

it doesn't seems to resize vertically at all.

The crash when resizing the overview windows is indeed fixed. Unfortunately it seems that there is a secondary problem (let me know if you want me to open a new ticket): resizing the overview windows is very slow, with both the "cache rendering" enabled or disabled. Just tested it with a couple of polygon/line layers (shapes, wfs).

#14 Updated by Jürgen Fischer over 8 years ago

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

should be fixed in 185ec5db (SVN r15051).

#15 Updated by Markus Neteler over 8 years ago

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

Having loaded two vector maps (LAEA, no reprojection on the fly), resizing the window leads to a crash. Logs of two events attached.

System: Linux north 2.6.33.7-desktop-2mnb #3905 SMP Mon Sep 20 18:19:20 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux

Qt 4.6.2

If it was fixed on trunk, please backport to 1.6 since it is a major showstopper.

#16 Updated by Paolo Cavallini over 8 years ago

I just got a crash resizing a window on f5b1607e (SVN r15261), so I'm not so sure it is fully fixed in trunk.

#17 Updated by Paolo Cavallini over 8 years ago

See also #2942, possibly duplicated

#18 Updated by Anne Ghisla over 8 years ago

I can reproduce this bug with a huge shapefile - 37k points - and resize the main window from a corner twice. It happens anytime, disregarding render caching setting.

f8e10a33 (SVN r15725), Qt 4.7.1

#19 Updated by Marco Hugentobler over 8 years ago

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

Hopefully fixed with f4d26d6 (tested with Qt 4.7 and 4.6.2 on Linux).

#20 Updated by Radim Blazek over 6 years ago

  • Assignee deleted (nobody -)
  • Priority changed from Low to Severe/Regression
  • Target version changed from Version 1.7.0 to Version 2.0.0
  • Pull Request or Patch supplied set to No
  • Crashes QGIS or corrupts data set to No
  • Affected QGIS version set to master
  • File resize-crash-backtrace.txtMagnifier added
  • Category changed from GUI to Map Canvas
  • Status changed from Closed to Reopened

I have the same problem with current master with single WMS layer on Debian 5.0 and Qt 4.6.1, backtrace attached.

I am not sure if it is still the same problem, but Qt 4.6 suggests that it could be and other people just upgraded Qt to 4.7 and problem was "resolved".

#21 Updated by Matthias Kuhn about 6 years ago

Could be related, based on the stack trace.

Can you try to enable backbuffering in Settings => Options => Rendering.

#22 Updated by Jürgen Fischer about 6 years ago

Radim Blazek wrote:

I have the same problem with current master with single WMS layer on Debian 5.0 and Qt 4.6.1, backtrace attached.

I am not sure if it is still the same problem, but Qt 4.6 suggests that it could be and other people just upgraded Qt to 4.7 and problem was "resolved".

lenny is oldoldstable. And if upgrading to Qt 4.7 helps, this might be a Qt problem after all. Should that really be a blocker?

#23 Updated by Jürgen Fischer about 6 years ago

  • Priority changed from Severe/Regression to Normal
  • Status changed from Reopened to Closed
  • Resolution changed from fixed to up-/downstream

Jürgen Fischer wrote:

lenny is oldoldstable. And if upgrading to Qt 4.7 helps, this might be a Qt problem after all. Should that really be a blocker?

Closing it again.

Also available in: Atom PDF