[Vista] GRASS plugin crashes QGIS when running the r.colors, r.null, v.dissolve modules

[pcav]

Running the r.colors.rules module causes QGIS to crash on Windows Vista. The command is correctly applied (when reopening the mapset the color table is applied), however. This happens also with other raster operations (eg removing a raster from the legend), so it may be due to visualization problem (GDAL-GRASS?).

[pcav]

the same command from the shell seem to work

[lutra]

v.dissolve seems to crash only under windows Seven, while the list of problematic modules under Vista/Seven is probably much more long.

These are just the modules that proved to crash QGIS while resolving a simple exercise during a qgis/grass course.

[micha]

I can verify the problem with r.colors on Vista only thru the gui. And, to add to the list, I found that r.mapcalculator also caused a crash, but not consistently. This was on a localized version of Vista. On the other hand, r.mapcalc worked fine.

[rblazek]

Am I right if I say: "QGIS crashes when a modified (rewritten) GRASS raster (previously added to canvas) is redrawn"?

The reason why it happens from GUI probably is, that when GRASS tool finishes, the canvas is automaticaly refreshed.

I guess the problem could be the difference between unix and windows file management which may have also changed in Vista. On unix it is possible remove a file which is opened by another program (OS keeps the old file (without name) until it is closed by the program it was using). On windows (XP) it is impossible AFAIR to delete a file opened by another application, it is possible however to move it!

Could you try some more precise tests? Just open a raster map in QGIS and redraw after each of following tests done in a file manager, don't resize etc. the QGIS window during the modifications of data so that you have control over when the map is redrawn:

1) update the 'last modified' file attribute of the colr/map file and redraw in QGIS

2) make a backup of your map, and try to overwrite all elemets (files - colr/map, cellhd/map ...) of the map with the backup version using copy. Try to redraw after each copy and see if QGIS crashes or if you can even overwrite the file.

3) another exercise like 2) but try to move to a temporary directory each map file before you make a copy from backup

4) try 2) and 3) but doing also 1) after a file was copied, that will force QGIS to reload the map instead of just reading

Please report if/when it is crashing doing that test.

[lutra]

Hi Radim, I'll try to do some Xp/Vista tests as soon as possible, I don't use windows so before I have to set up the virtual machines. However I don't have a Seven license, so I cannot make tests with this platform.

Thanks in advance (a lot!)

[lutra]

I'll try also Dbgview.exe and let you know asap.

[lutra]

Tested under Vista 32 bit with qgis 1.4. Opened the grass location available in the qgis sample dataset, added the raster available in the "demo" mapset.

When applying r.colors.table qgis crashes and dgbview returns

[3820] d:\progs\c\qgis-build\src\qgis\qgis_unstable\src\plugins\grass\qgsgrassmodule.cpp(1014) : (QgsGrassModule::pixmap) path = C:/OSGeo4W/apps/qgis-dev/./grass/modules/r.colors.table
[3820] d:\progs\c\qgis-build\src\qgis\qgis_unstable\src\plugins\grass\qgsgrassmodule.cpp(1130) : (QgsGrassModule::run) called.
[3820] d:\progs\c\qgis-build\src\qgis\qgis_unstable\src\plugins\grass\qgsgrassmodule.cpp(791) : (QgsGrassModuleStandardOptions::ready) entered.
[3820] d:\progs\c\qgis-build\src\qgis\qgis_unstable\src\plugins\grass\qgsgrassmodule.cpp(2528) : (QgsGrassModuleInput::ready) called.
[3820] d:\progs\c\qgis-build\src\qgis\qgis_unstable\src\plugins\grass\qgsgrassmodule.cpp(2532) : (QgsGrassModuleInput::ready) count = 2
[3820] d:\progs\c\qgis-build\src\qgis\qgis_unstable\src\plugins\grass\qgsgrassmodule.cpp(1962) : (QgsGrassModuleOption::ready) called.
[3820] d:\progs\c\qgis-build\src\qgis\qgis_unstable\src\plugins\grass\qgsgrassmodule.cpp(940) : (QgsGrassModuleStandardOptions::requestsRegion) called.
[3820] d:\progs\c\qgis-build\src\qgis\qgis_unstable\src\plugins\grass\qgsgrassmodule.cpp(2220) : (QgsGrassModuleInput::useRegion) called.
[3820] d:\progs\c\qgis-build\src\qgis\qgis_unstable\src\plugins\grass\qgsgrassmodule.cpp(956) : (QgsGrassModuleStandardOptions::usesRegion) called.
[3820] d:\progs\c\qgis-build\src\qgis\qgis_unstable\src\plugins\grass\qgsgrassmodule.cpp(2220) : (QgsGrassModuleInput::useRegion) called.
[3820] d:\progs\c\qgis-build\src\qgis\qgis_unstable\src\plugins\grass\qgsgrassmodule.cpp(971) : (QgsGrassModuleStandardOptions::usesRegion) NO usesRegion()
[3820] d:\progs\c\qgis-build\src\qgis\qgis_unstable\src\plugins\grass\qgsgrassmodule.cpp(600) : (QgsGrassModuleStandardOptions::checkOutput) called.
[3820] d:\progs\c\qgis-build\src\qgis\qgis_unstable\src\plugins\grass\qgsgrassmodule.cpp(609) : (QgsGrassModuleStandardOptions::checkOutput) opt->key() = color
[3820] d:\progs\c\qgis-build\src\qgis\qgis_unstable\src\plugins\grass\qgsgrassmodule.cpp(765) : (QgsGrassModuleStandardOptions::output) called.
[3820] d:\progs\c\qgis-build\src\qgis\qgis_unstable\src\plugins\grass\qgsgrassmodule.cpp(774) : (QgsGrassModuleStandardOptions::output) opt->key() = color
[3820] d:\progs\c\qgis-build\src\qgis\qgis_unstable\src\plugins\grass\qgsgrassmodule.cpp(1222) : (QgsGrassModule::run) mOutputVector.size() = 0
[3820] d:\progs\c\qgis-build\src\qgis\qgis_unstable\src\plugins\grass\qgsgrassmodule.cpp(765) : (QgsGrassModuleStandardOptions::output) called.
[3820] d:\progs\c\qgis-build\src\qgis\qgis_unstable\src\plugins\grass\qgsgrassmodule.cpp(774) : (QgsGrassModuleStandardOptions::output) opt->key() = color
[3820] d:\progs\c\qgis-build\src\qgis\qgis_unstable\src\plugins\grass\qgsgrassmodule.cpp(1224) : (QgsGrassModule::run) mOutputRaster.size() = 0
[3820] d:\progs\c\qgis-build\src\qgis\qgis_unstable\src\plugins\grass\qgsgrassmodule.cpp(1233) : (QgsGrassModule::run) option: map=gtopo30@demo
[3820] d:\progs\c\qgis-build\src\qgis\qgis_unstable\src\plugins\grass\qgsgrassmodule.cpp(1233) : (QgsGrassModule::run) option: color=byg
[3820] d:\progs\c\qgis-build\src\qgis\qgis_unstable\src\plugins\grass\qgsgrassmodule.cpp(1263) : (QgsGrassModule::run) command: r.colors map=gtopo30@demo color=byg
[3820] d:\progs\c\qgis-build\src\qgis\qgis_unstable\src\plugins\grass\qgsgrassmodule.cpp(56) : (QgsGrassModule::findExec) called.
[3820] d:\progs\c\qgis-build\src\qgis\qgis_unstable\src\plugins\grass\qgsgrassmodule.cpp(56) : (QgsGrassModule::findExec) called.
[3820] d:\progs\c\qgis-build\src\qgis\qgis_unstable\src\plugins\grass\qgsgrassmodule.cpp(626) : (QgsGrassModuleStandardOptions::freezeOutput) called.
[3820] d:\progs\c\qgis-build\src\qgis\qgis_unstable\src\plugins\grass\qgsgrassmodule.cpp(635) : (QgsGrassModuleStandardOptions::freezeOutput) opt->key() = color
[2076] Invalid parameter passed to C runtime function.
[3820] d:\progs\c\qgis-build\src\qgis\qgis_unstable\src\plugins\grass\qgsgrassmodule.cpp(1434) : (QgsGrassModule::readStderr) called.
[3820] d:\progs\c\qgis-build\src\qgis\qgis_unstable\src\plugins\grass\qgsgrassmodule.cpp(1377) : (QgsGrassModule::finished) called.
[3820] d:\progs\c\qgis-build\src\qgis\qgis_unstable\src\plugins\grass\qgsgrassmodule.cpp(1379) : (QgsGrassModule::finished) exitCode = 0
[3820] d:\progs\c\qgis-build\src\qgis\qgis_unstable\src\plugins\grass\qgsgrassmodule.cpp(695) : (QgsGrassModuleStandardOptions::thawOutput) called.
[3820] d:\progs\c\qgis-build\src\qgis\qgis_unstable\src\plugins\grass\qgsgrassmodule.cpp(704) : (QgsGrassModuleStandardOptions::thawOutput) opt->key() = color
[3820] d:\progs\c\qgis-build\src\qgis\qgis_unstable\src\core\qgsmaprenderer.cpp(212) : (QgsMapRenderer::render) ========== Rendering ==========
[3820] d:\progs\c\qgis-build\src\qgis\qgis_unstable\src\core\qgsmaprenderer.cpp(236) : (QgsMapRenderer::render) Starting to render layer stack.
[3820] d:\progs\c\qgis-build\src\qgis\qgis_unstable\src\core\qgsmaprenderer.cpp(323) : (QgsMapRenderer::render) Rendering at layer item gtopo3020100109171834210
[3820] d:\progs\c\qgis-build\src\qgis\qgis_unstable\src\core\qgsmaprenderer.cpp(331) : (QgsMapRenderer::render) If there is a QPaintEngine error here, it is caused by an emit call
[3820] d:\progs\c\qgis-build\src\qgis\qgis_unstable\src\core\qgsmaprenderer.cpp(342) : (QgsMapRenderer::render) Rendering layer gtopo30
[3820] d:\progs\c\qgis-build\src\qgis\qgis_unstable\src\core\qgsmaprenderer.cpp(343) : (QgsMapRenderer::render)   Layer minscale 0
[3820] d:\progs\c\qgis-build\src\qgis\qgis_unstable\src\core\qgsmaprenderer.cpp(344) : (QgsMapRenderer::render)   Layer maxscale 1e+08
[3820] d:\progs\c\qgis-build\src\qgis\qgis_unstable\src\core\qgsmaprenderer.cpp(345) : (QgsMapRenderer::render)   Scale dep. visibility enabled? 0
[3820] d:\progs\c\qgis-build\src\qgis\qgis_unstable\src\core\qgsmaprenderer.cpp(346) : (QgsMapRenderer::render)   Input extent: -7117600.0000000000000000,1367760.0000000000000000 : 4897040.0000000000000000,7809680.0000000000000000
[3820] d:\progs\c\qgis-build\src\qgis\qgis_unstable\src\core\raster\qgsrasterlayer.cpp(1418) : (QgsRasterLayer::draw) entered. (renderContext)
[3820] d:\progs\c\qgis-build\src\qgis\qgis_unstable\src\core\raster\qgsrasterlayer.cpp(1424) : (QgsRasterLayer::draw) checking timestamp.
[3820] d:\progs\c\qgis-build\src\qgis\qgis_unstable\src\core\raster\qgsrasterlayer.cpp(5423) : (QgsRasterLayer::update) entered.
[3820] d:\progs\c\qgis-build\src\qgis\qgis_unstable\src\core\raster\qgsrasterlayer.cpp(482) : (QgsRasterLayer::lastModified) name=C:/Users/gio/Downloads/qgis_sample_data/qgis_sample_data/grassdata/alaska/demo/cellhd/gtopo30
[3820] d:\progs\c\qgis-build\src\qgis\qgis_unstable\src\core\raster\qgsrasterlayer.cpp(544) : (QgsRasterLayer::lastModified) last modified = Sat Jan 9 17:19:48 2010
[3820] d:\progs\c\qgis-build\src\qgis\qgis_unstable\src\core\raster\qgsrasterlayer.cpp(5427) : (QgsRasterLayer::update) Outdated -> reload

[lutra]

PS

when you open again the grass raster after the crash the new colormap is ok.

[lutra]

While trying to test again v.dissolve it happens that another bug now pops out under windows, see #2351

[lutra]

Replying to rblazek:

Please report if/when it is crashing doing that test.

none of the suggested tests seems to induce a crash in qgis.

Tested under Vista 32 bit and qgis trunk.

[lutra]

Replying to rblazek: Try to redraw after each copy and see if QGIS crashes or if you can even overwrite the file.

Yes, Vista allow to overwrite all files in the location. You can also move them, except for /fcell/rasterinuse

[rblazek]

Thanks for doing the test, especially the output from dbgview is very useful. The crash happens when the raster is updated, and update() just calls closeDataset() and readFile(). Suspicious is closeDataset() (we know readFile works, and there is also #1945 (also calling closeDataset()) which could be the same).

The backtrace would tell us more, can't you get it from dbgview? I mean the sequence of functions called before crash, that should end by the function in which it crashed. On debugview page they say:"Crash-Dump Support:DebugView can recover its buffers from a crash dump and save the output to a log file so that users can send you the output your Windows driver generated right up to the time of a crash."

I have looked into the GRASSRasterBand::~GRASSRasterBand() (called by QgsRasterLayer::closeDataset) but I cannot find anything wrong.

Strange thing is, that you cannot get the crash just by updating the colr/gtopo30 file, it should result in the same situation.

[rblazek]

Probably duplicates #1945

[lutra]

Hi, sorry for the late answer but I was pretty busy.

I seen in #1945 that you made some advance. Do you still want me to do further tests under Vista (that in any case I can only run in a VM)?

[rblazek]

Replying to lutra:

I seen in #1945 that you made some advance. Do you still want me to do further tests under Vista (that in any case I can only run in a VM)?

I don't think that you can get more info without 'symbol files', I don't know where to get them without recompiling yourself QGIS and GDAL, maybe GRASS on windows!

The chain from GRASS to QGIS display via GDAL is too long, too hacky and out of our control. Fixes for GRASS or GDAL take a long time to get to distributions. I'll write native GRASS raster driver and it should fix this and #1945 and of course, it will introduce a lot of new issues.

[rblazek]

Fixed in r12880 - new GRASS raster data provider

[lutra]

Hi Radim, thanks a lot.

I'm reinstalling Vista in a VM, then I'll give you feedback asap.

cheers

[lutra]

So...

tested again under Vista32, Xp and Linux.

r.colors: now does *not* crash Vista, nevertheless the raster with the new colormap is not automatically refreshed in the canvas and in the legend (also under xp and linux). There was a ticket about the same (minor) problem that was closed during 2009.

r.null:

still crashes qgis under Vista. No crash under xp and linux.

To notice the following: when testing r.null under Vista (and crashes qgis), when reopening the mapset, the raster seems corrupted. The colormap is corrupted and the same messages reposted here

​https://trac.osgeo.org/qgis/ticket/1945#comment:17

are thrown by qgis/value tool.

Still not possible to test v.dissolve as actually the module is bugged (but used to work) on both linux and windows (see #2351).

[lutra]

More on r.null and Vista:

the messages as seen in #1945 (comment 17 >) do depend if the "value tool" plugin is installed. Nevertheless, after crashing, the raster where r.null was applied results corrupted.

[lutra]

More (puzzling) stuff on r.colors.*

On linux and xp it, as already said, it seems to do not automatically refresh anymore the canvas and the legend after applying a r.colors rule.

On Vista it seems to works "fine", it refreshes the canvas but not the legend*. A few more notes about Vista:

If I try to apply a r.colors rule in the raster already (gtopo30) already present in the qgis sample dataset, I always get corrupted colormaps.

If I create manually a mapset equal to the above, import in it the "landcover.img" raster and the apply r.colors, then it works fine.

During test I tried to import the following raster

​http://www.faunalia.it/qgis/data/srtm30-relief.zip

with r.in and the result is always a raster with a corrupted colormap.

* I'm having an hard time now to remember if the r.colors commands also refreshed the raster icon in the legend, I believe that the answer is yes.

[rblazek]

Replying to lutra:

Please don't mix too many distinct problems in one ticket (v.dissolve,r.null,r.colors!)

More (puzzling) stuff on r.colors.*

On linux and xp it, as already said, it seems to do not automatically refresh anymore the canvas and the legend after applying a r.colors rule.

It depends if the raster was added from grass toolbar or browser/module, because browser/module are using GDAL but refresh was disabled in raster layer (was hack for GRASS). It is already fixed, I have wrote about it somewhere.

If I try to apply a r.colors rule in the raster already (gtopo30) already present in the qgis sample dataset, I always get corrupted colormaps.

Works for me.

During test I tried to import the following raster ​http://www.faunalia.it/qgis/data/srtm30-relief.zip with r.in and the result is always a raster with a corrupted colormap.

Corrupted colormap in raster database or it is not correctly drawn in QGIS? Is it realy related to this ticket?

* I'm having an hard time now to remember if the r.colors commands also refreshed the raster icon in the legend, I believe that the answer is yes.

The legend is currently hardcoded in qgsrasterlayer for layers using a provider.

[lutra]

Replying to rblazek:

Please don't mix too many distinct problems in one ticket (v.dissolve,r.null,r.colors!)

sorry, you are right.

It depends if the raster was added from grass toolbar or browser/module, because browser/module are using GDAL but refresh was disabled in raster layer (was hack for GRASS). It is already fixed, I have wrote about it somewhere.

Ok got it.

If I try to apply a r.colors rule in the raster already (gtopo30) already present in the qgis sample dataset, I always get corrupted colormaps.

Works for me.

During test I tried to import the following raster ​http://www.faunalia.it/qgis/data/srtm30-relief.zip with r.in and the result is always a raster with a corrupted colormap.

Corrupted colormap in raster database or it is not correctly drawn in QGIS?

Not correctly drawn by qgis. As I said in #1945 it seems to depend if you add the raster trough the qgis GRASS toolbar (colors scrambled) or trough the GRASS browser (colors ok).

Is it realy related to this ticket?

Well... I guess so, as the issues I'm speaking in these last comments are all side effects of the last changes in the code(?).

The legend is currently hardcoded in qgsrasterlayer for layers using a provider.

Just checked in qgis 1.4: legend icon is not refreshed after applying a color rule (for example), nevertheless it appears clearly as small square version of the raster (GRASS or non GRASS) in the canvas. In the actual qgis trunk no icon is associated to the raster name in the legend and a small color ramp is shown instead (see attached image). Don't know if this is related to the last changes in the code regarding GRASS rasters.

[lutra]

raster legend icons in trunk and 1.4

[rblazek]

Replying to lutra:

During test I tried to import the following raster ​http://www.faunalia.it/qgis/data/srtm30-relief.zip with r.in and the result is always a raster with a corrupted colormap.

Corrupted colormap in raster database or it is not correctly drawn in QGIS?

Not correctly drawn by qgis.

Imported with r.in.gdal, I have got exactly the same like in GRASS mon.

As I said in #1945 it seems to depend if you add the raster trough the qgis GRASS toolbar (colors scrambled) or trough the GRASS browser (colors ok).

But that is still the same problem which was fixed yesterday, now you should get the same everywhere.

The legend is currently hardcoded in qgsrasterlayer for layers using a provider.

In the actual qgis trunk no icon is associated to the raster name in the legend and a small color ramp is shown instead (see attached image). Don't know if this is related to the last changes in the code regarding GRASS rasters.

Again the same problem, poor support for raster providers in QGIS as I said above, no way pass legend image from provider at moment.

[lutra]

Another probable good news: r.null seems to not crash anymore qgis under Vista. More tests would be needed. Tomorrow.

[lutra]

Replying to lutra:

Another probable good news: r.null seems to not crash anymore qgis under Vista. More tests would be needed. Tomorrow.

I made a couple of test and it seems really that r.null do not crash anymore under Vista and it works fine. r.colors also seem to work fine, so of the title of this ticket it remains de v.dissolve problem that obviously has nothing to do with rasters.

v.dissolve meanwhile become bugged so I cannot try to reproduce the problem right now. I'll wait for v.dissolve to be fixed than I'll eventually open a new ticket.