Bug report #15780
QGIS 2.18 crashes while rendering (Windows 10)
|Affected QGIS version:||2.18.0||Regression?:||No|
|Operating System:||Windows||Easy fix?:||No|
|Pull Request or Patch supplied:||No||Resolution:||worksforme|
|Crashes QGIS or corrupts data:||Yes||Copied to github as #:||23701|
While my large project file (140+ postgis layers) rendered perfectly on screen in 2.16, QGIS 2.18 crashes unpredictably while rendering on screen. This happens each time within a few minutes after opening my project file.
The error message is a pure virtual function call, resulting in a "mini dump", no further details specified.
Decreasing the number of cores to simultaneously use to render doesn't help.
Decreasing the draw interval time (from 1 second to 0.2 seconds) seems to help a little, but it doesn't solve the problem. It seems to crash while working on the rendering of the text labels, but I can't be sure.
I am using QGIS Desktop 2.18 with Windows 10 64-bit.
#1 Updated by Richard Duivenvoorde over 4 years ago
Hi Jan Willem,
without more information devs cannot dive into this.
I'm not familiar enough with Windows minidumps/crashes to be helpfull in this.
Did you try:
- another QGIS instance on another machine
- start with a fresh config?
- enable/disable the parallel rendering options?
I know your dataset, so I know it is hard to share. But if it is a clean project file, I would try to do it using a Linux desktop. One because (I think) it is just more stable, but more because it is easier to get a backtrace IF there is a crash.
#2 Updated by JW van Aalst over 4 years ago
Thank you Richard for your tips.
I've found that it doesn't just happen with the large QGIS project file, but also with very simple project files.
Enabling/disabling the parallel rendering options unfortunately doesn't solve this.
One thing I've noticed is that when I use only my 1920x1080 laptop screen, 2.18 does not crash. When I use my 2560x1440 external screen, 2.18 crashes. So perhaps it is related to my graphics driver. This was never a problem before 2.18, though.
I'm happy to attach one of the mini-dumps, if you can tell me the regular file path where such files are written to.
I will try to install QGIS 2.18 on another machine and try both large and simple project files, using the main screen and a separate external monitor screen. I will report the results shortly.
#3 Updated by Klas Karlsson over 4 years ago
(Might be unrelated)
It also crash a lot on my Linux (Ubuntu 16.04) machine. Not quite sure how to debug, but from the logs the following lines are created at the time of crash:
ERROR: apport (pid 15006) Thu Nov 3 16:01:10 2016: called for pid 6024, signal 11, core limit 0
ERROR: apport (pid 15006) Thu Nov 3 16:01:10 2016: executable: /usr/bin/qgis.bin (command line "/usr/bin/qgis.bin")
ERROR: apport (pid 15006) Thu Nov 3 16:01:10 2016: debug: session gdbus call: (true,)
ERROR: apport (pid 15006) Thu Nov 3 16:01:10 2016: this executable already crashed 2 times, ignoring
Nov 3 16:01:10 Deathstar kernel: [ 4713.161288] traps: Thread (pooled) general protection ip:7f5bcf18a0ef sp:7f5b09ff9c40 error:0 in libQtGui.so.4.8.7[7f5bcee7a000+aac000]_
Not really sure, but it may be a problem related to PostGIS... Can't get it to crash with only shape files...
#4 Updated by Dmitry Kravchook over 4 years ago
It seems that memory management is broken while rendering. In print composer, while render, if layers in map uses mixing and resulting image is big enough (depends on available phisical memory) this layers are ignored. 2.16 works perfect on the same conditions.
#7 Updated by Giovanni Manghi over 4 years ago
- Category set to Project Loading/Saving
- Status changed from Open to Feedback
Please also try in clean environment, with no 3rd party plugins and possibly by wiping the entire .qgis2 folder.
Without any project/data to test seems very improbable to me to find the source of the issue.
#8 Updated by JW van Aalst over 4 years ago
I did a clean install of QGIS Desktop 2.18.4 on Windows 10 64-bit.
I tried it on my topo project file containing over 200 PostGIS map layers.
The application crashes considerably less often than on 2.18.1. My estimation is only once in about 60-80 screen renderings.
This is acceptable to me.