QGIS » QGIS Application

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).

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.

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;

I applied the workaround in f8b728bd (SVN r13501).

workaround fixes the crash.

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

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

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

Replying to [comment:11 jef]:

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

185ec5db (SVN r15051) that is.

see also #2339

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

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).

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).

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

See also #2942, possibly duplicated

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

Could be related, based on the stack trace.

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

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?