Bug report #2028

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

Added by Paolo Cavallini almost 11 years ago. Updated over 10 years ago.

Status:Closed
Priority:Low
Assignee:Lorenzo Masini
Category:GRASS
Affected QGIS version: Regression?:No
Operating System:Windows Easy fix?:No
Pull Request or Patch supplied: Resolution:fixed
Crashes QGIS or corrupts data: Copied to github as #:12088

Description

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

Screenshot.png - raster legend icons in trunk and 1.4 (28.6 KB) Giovanni Manghi, 2010-02-05 05:52 PM

History

#1 Updated by Paolo Cavallini almost 11 years ago

the same command from the shell seem to work

#2 Updated by Giovanni Manghi over 10 years ago

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.

#3 Updated by Micha Silver over 10 years ago

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.

#4 Updated by Redmine Admin over 10 years ago

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.

#5 Updated by Giovanni Manghi over 10 years ago

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

#6 Updated by Giovanni Manghi over 10 years ago

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

#7 Updated by Giovanni Manghi over 10 years ago

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

 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
 d:\\progs\\c\\qgis-build\\src\\qgis\\qgis_unstable\\src\\plugins\\grass\\qgsgrassmodule.cpp(1130) : (QgsGrassModule::run) called.
 d:\\progs\\c\\qgis-build\\src\\qgis\\qgis_unstable\\src\\plugins\\grass\\qgsgrassmodule.cpp(791) : (QgsGrassModuleStandardOptions::ready) entered.
 d:\\progs\\c\\qgis-build\\src\\qgis\\qgis_unstable\\src\\plugins\\grass\\qgsgrassmodule.cpp(2528) : (QgsGrassModuleInput::ready) called.
 d:\\progs\\c\\qgis-build\\src\\qgis\\qgis_unstable\\src\\plugins\\grass\\qgsgrassmodule.cpp(2532) : (QgsGrassModuleInput::ready) count = 2
 d:\\progs\\c\\qgis-build\\src\\qgis\\qgis_unstable\\src\\plugins\\grass\\qgsgrassmodule.cpp(1962) : (QgsGrassModuleOption::ready) called.
 d:\\progs\\c\\qgis-build\\src\\qgis\\qgis_unstable\\src\\plugins\\grass\\qgsgrassmodule.cpp(940) : (QgsGrassModuleStandardOptions::requestsRegion) called.
 d:\\progs\\c\\qgis-build\\src\\qgis\\qgis_unstable\\src\\plugins\\grass\\qgsgrassmodule.cpp(2220) : (QgsGrassModuleInput::useRegion) called.
 d:\\progs\\c\\qgis-build\\src\\qgis\\qgis_unstable\\src\\plugins\\grass\\qgsgrassmodule.cpp(956) : (QgsGrassModuleStandardOptions::usesRegion) called.
 d:\\progs\\c\\qgis-build\\src\\qgis\\qgis_unstable\\src\\plugins\\grass\\qgsgrassmodule.cpp(2220) : (QgsGrassModuleInput::useRegion) called.
 d:\\progs\\c\\qgis-build\\src\\qgis\\qgis_unstable\\src\\plugins\\grass\\qgsgrassmodule.cpp(971) : (QgsGrassModuleStandardOptions::usesRegion) NO usesRegion()
 d:\\progs\\c\\qgis-build\\src\\qgis\\qgis_unstable\\src\\plugins\\grass\\qgsgrassmodule.cpp(600) : (QgsGrassModuleStandardOptions::checkOutput) called.
 d:\\progs\\c\\qgis-build\\src\\qgis\\qgis_unstable\\src\\plugins\\grass\\qgsgrassmodule.cpp(609) : (QgsGrassModuleStandardOptions::checkOutput) opt->key() = color
 d:\\progs\\c\\qgis-build\\src\\qgis\\qgis_unstable\\src\\plugins\\grass\\qgsgrassmodule.cpp(765) : (QgsGrassModuleStandardOptions::output) called.
 d:\\progs\\c\\qgis-build\\src\\qgis\\qgis_unstable\\src\\plugins\\grass\\qgsgrassmodule.cpp(774) : (QgsGrassModuleStandardOptions::output) opt->key() = color
 d:\\progs\\c\\qgis-build\\src\\qgis\\qgis_unstable\\src\\plugins\\grass\\qgsgrassmodule.cpp(1222) : (QgsGrassModule::run) mOutputVector.size() = 0
 d:\\progs\\c\\qgis-build\\src\\qgis\\qgis_unstable\\src\\plugins\\grass\\qgsgrassmodule.cpp(765) : (QgsGrassModuleStandardOptions::output) called.
 d:\\progs\\c\\qgis-build\\src\\qgis\\qgis_unstable\\src\\plugins\\grass\\qgsgrassmodule.cpp(774) : (QgsGrassModuleStandardOptions::output) opt->key() = color
 d:\\progs\\c\\qgis-build\\src\\qgis\\qgis_unstable\\src\\plugins\\grass\\qgsgrassmodule.cpp(1224) : (QgsGrassModule::run) mOutputRaster.size() = 0
 d:\\progs\\c\\qgis-build\\src\\qgis\\qgis_unstable\\src\\plugins\\grass\\qgsgrassmodule.cpp(1233) : (QgsGrassModule::run) option: [email protected]
 d:\\progs\\c\\qgis-build\\src\\qgis\\qgis_unstable\\src\\plugins\\grass\\qgsgrassmodule.cpp(1233) : (QgsGrassModule::run) option: color=byg
 d:\\progs\\c\\qgis-build\\src\\qgis\\qgis_unstable\\src\\plugins\\grass\\qgsgrassmodule.cpp(1263) : (QgsGrassModule::run) command: r.colors [email protected] color=byg
 d:\\progs\\c\\qgis-build\\src\\qgis\\qgis_unstable\\src\\plugins\\grass\\qgsgrassmodule.cpp(56) : (QgsGrassModule::findExec) called.
 d:\\progs\\c\\qgis-build\\src\\qgis\\qgis_unstable\\src\\plugins\\grass\\qgsgrassmodule.cpp(56) : (QgsGrassModule::findExec) called.
 d:\\progs\\c\\qgis-build\\src\\qgis\\qgis_unstable\\src\\plugins\\grass\\qgsgrassmodule.cpp(626) : (QgsGrassModuleStandardOptions::freezeOutput) called.
 d:\\progs\\c\\qgis-build\\src\\qgis\\qgis_unstable\\src\\plugins\\grass\\qgsgrassmodule.cpp(635) : (QgsGrassModuleStandardOptions::freezeOutput) opt->key() = color
 Invalid parameter passed to C runtime function.
 d:\\progs\\c\\qgis-build\\src\\qgis\\qgis_unstable\\src\\plugins\\grass\\qgsgrassmodule.cpp(1434) : (QgsGrassModule::readStderr) called.
 d:\\progs\\c\\qgis-build\\src\\qgis\\qgis_unstable\\src\\plugins\\grass\\qgsgrassmodule.cpp(1377) : (QgsGrassModule::finished) called.
 d:\\progs\\c\\qgis-build\\src\\qgis\\qgis_unstable\\src\\plugins\\grass\\qgsgrassmodule.cpp(1379) : (QgsGrassModule::finished) exitCode = 0
 d:\\progs\\c\\qgis-build\\src\\qgis\\qgis_unstable\\src\\plugins\\grass\\qgsgrassmodule.cpp(695) : (QgsGrassModuleStandardOptions::thawOutput) called.
 d:\\progs\\c\\qgis-build\\src\\qgis\\qgis_unstable\\src\\plugins\\grass\\qgsgrassmodule.cpp(704) : (QgsGrassModuleStandardOptions::thawOutput) opt->key() = color
 d:\\progs\\c\\qgis-build\\src\\qgis\\qgis_unstable\\src\\core\\qgsmaprenderer.cpp(212) : (QgsMapRenderer::render) ========== Rendering ==========
 d:\\progs\\c\\qgis-build\\src\\qgis\\qgis_unstable\\src\\core\\qgsmaprenderer.cpp(236) : (QgsMapRenderer::render) Starting to render layer stack.
 d:\\progs\\c\\qgis-build\\src\\qgis\\qgis_unstable\\src\\core\\qgsmaprenderer.cpp(323) : (QgsMapRenderer::render) Rendering at layer item gtopo3020100109171834210
 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
 d:\\progs\\c\\qgis-build\\src\\qgis\\qgis_unstable\\src\\core\\qgsmaprenderer.cpp(342) : (QgsMapRenderer::render) Rendering layer gtopo30
 d:\\progs\\c\\qgis-build\\src\\qgis\\qgis_unstable\\src\\core\\qgsmaprenderer.cpp(343) : (QgsMapRenderer::render)   Layer minscale 0
 d:\\progs\\c\\qgis-build\\src\\qgis\\qgis_unstable\\src\\core\\qgsmaprenderer.cpp(344) : (QgsMapRenderer::render)   Layer maxscale 1e+08
 d:\\progs\\c\\qgis-build\\src\\qgis\\qgis_unstable\\src\\core\\qgsmaprenderer.cpp(345) : (QgsMapRenderer::render)   Scale dep. visibility enabled? 0
 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
 d:\\progs\\c\\qgis-build\\src\\qgis\\qgis_unstable\\src\\core\
aster\\qgsrasterlayer.cpp(1418) : (QgsRasterLayer::draw) entered. (renderContext)
 d:\\progs\\c\\qgis-build\\src\\qgis\\qgis_unstable\\src\\core\
aster\\qgsrasterlayer.cpp(1424) : (QgsRasterLayer::draw) checking timestamp.
 d:\\progs\\c\\qgis-build\\src\\qgis\\qgis_unstable\\src\\core\
aster\\qgsrasterlayer.cpp(5423) : (QgsRasterLayer::update) entered.
 d:\\progs\\c\\qgis-build\\src\\qgis\\qgis_unstable\\src\\core\
aster\\qgsrasterlayer.cpp(482) : (QgsRasterLayer::lastModified) name=C:/Users/gio/Downloads/qgis_sample_data/qgis_sample_data/grassdata/alaska/demo/cellhd/gtopo30
 d:\\progs\\c\\qgis-build\\src\\qgis\\qgis_unstable\\src\\core\
aster\\qgsrasterlayer.cpp(544) : (QgsRasterLayer::lastModified) last modified = Sat Jan 9 17:19:48 2010
 d:\\progs\\c\\qgis-build\\src\\qgis\\qgis_unstable\\src\\core\
aster\\qgsrasterlayer.cpp(5427) : (QgsRasterLayer::update) Outdated -> reload

#8 Updated by Giovanni Manghi over 10 years ago

PS

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

#9 Updated by Giovanni Manghi over 10 years ago

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

#10 Updated by Giovanni Manghi over 10 years ago

Replying to [comment:5 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.

#11 Updated by Giovanni Manghi over 10 years ago

Replying to [comment:5 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

#12 Updated by Redmine Admin over 10 years ago

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.

#13 Updated by Redmine Admin over 10 years ago

Probably duplicates #1945

#14 Updated by Giovanni Manghi over 10 years ago

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

#15 Updated by Redmine Admin over 10 years ago

Replying to [comment:15 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.

#16 Updated by Redmine Admin over 10 years ago

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

Fixed in 728ecc69 (SVN r12881) - new GRASS raster data provider

#17 Updated by Giovanni Manghi over 10 years ago

Hi Radim, thanks a lot.

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

cheers

#18 Updated by Giovanni Manghi over 10 years ago

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

#19 Updated by Giovanni Manghi over 10 years ago

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.

#20 Updated by Giovanni Manghi over 10 years ago

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.

#21 Updated by Redmine Admin over 10 years ago

Replying to [comment:21 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.

#22 Updated by Giovanni Manghi over 10 years ago

Replying to [comment:22 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.

#23 Updated by Redmine Admin over 10 years ago

Replying to [comment:23 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.

#24 Updated by Giovanni Manghi over 10 years ago

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

#25 Updated by Giovanni Manghi over 10 years ago

Replying to [comment:25 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.

Also available in: Atom PDF