QGIS » QGIS Application

Please test with a very recent version (dev): this should have been fixed

Hi pcav,
with 1.4.0 (dev) it works fine on XP now, thanks.
On Vista32 and Vista64 it still crashes.

confirmed on Vista 32 bit with the lastest dev version available with the osgeo4w installer. Should we file the "Vista only" bugs also on the osgeo4w trac?

Could you send a backtrace or debug log?

Hi,

I send the problem details of the crash on vista32. Does it help?

Problem signature:
Problem event name: APPCRASH
Application name: qgis.exe
Application version: 0.0.0.0
Time stamp: 4b42812c
Error module name: ntdll.dll
Error module version: 6.0.6001.18000
Error module time stamp: 4791a7a6
Exception code: c0000005
Exception offset: 0006a75e
Operating system version: 6.0.6001.2.1.0.256.6
Area-Scheme ID: 1033
Additional information 1: da0e
Additional information 2: 10ad313fd9e790fb3f7caf35d412f6db
Additional information 3: 6d43
Additional information 4: 1195306449dea250be9623273a13009e

Replying to [comment:8 juanelz]:

Unfortunately this does not tell much. I dont know if it si possible to get on Windows something like backtrace output form debugger. I mean the chain of functions called before the crash.

It should be at least possible to get debug output printed by QGIS (I hope it is compiled with debug enabled). Try to run qgis from command line. Maybe qDebug writes to some system logs? Anybody can help?

Thank you, anyway.

I was told (jef/irc) to get debugview or start in the debugger.
http://live.sysinternals.com/Dbgview.exe if running the nightly build.

juanelz, can you try please with debugview.

Tested under Vista 32 bit with dbgview, it returns

 d:\\progs\\c\\qgis-build\\src\\qgis\\qgis_unstable\\src\\core\
aster\\qgsrasterlayer.cpp(1921) : (QgsRasterLayer::identify) -7608945.87161, 5047052.03994
 d:\\progs\\c\\qgis-build\\src\\qgis\\qgis_unstable\\src\\app\\legend\\qgslegend.cpp(182) : (QgsLegend::removeLayer) called.
 d:\\progs\\c\\qgis-build\\src\\qgis\\qgis_unstable\\src\\core\\qgsmaprenderer.cpp(803) : (QgsMapRenderer::updateFullExtent) called.
 d:\\progs\\c\\qgis-build\\src\\qgis\\qgis_unstable\\src\\core\\qgsmaprenderer.cpp(860) : (QgsMapRenderer::updateFullExtent) Full extent: 179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368.0000000000000000,179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368.0000000000000000 : -179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368.0000000000000000,-179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368.0000000000000000
 d:\\progs\\c\\qgis-build\\src\\qgis\\qgis_unstable\\src\\core\\qgsmaprenderer.cpp(803) : (QgsMapRenderer::updateFullExtent) called.
 d:\\progs\\c\\qgis-build\\src\\qgis\\qgis_unstable\\src\\core\\qgsmaprenderer.cpp(860) : (QgsMapRenderer::updateFullExtent) Full extent: 179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368.0000000000000000,179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368.0000000000000000 : -179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368.0000000000000000,-179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368.0000000000000000
 d:\\progs\\c\\qgis-build\\src\\qgis\\qgis_unstable\\src\\gui\\qgsmapoverviewcanvas.cpp(162) : (QgsMapOverviewCanvas::drawExtentRect) panning: extent to widget: [-2147483648,-2147483648] [1x1]
 d:\\progs\\c\\qgis-build\\src\\qgis\\qgis_unstable\\src\\gui\\qgsmapcanvas.cpp(305) : (QgsMapCanvas::setLayerSet) Layers have changed, refreshing
 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(509) : (QgsMapRenderer::render) Done rendering map layers
 d:\\progs\\c\\qgis-build\\src\\qgis\\qgis_unstable\\src\\plugins\\labeling\\pallabeling.cpp(472) : (PalLabeling::drawLabeling) LABELING work:  0 ms ... labels# 0
 d:\\progs\\c\\qgis-build\\src\\qgis\\qgis_unstable\\src\\plugins\\labeling\\pallabeling.cpp(489) : (PalLabeling::drawLabeling) LABELING draw:  0 ms
 d:\\progs\\c\\qgis-build\\src\\qgis\\qgis_unstable\\src\\core\\qgsmaprenderer.cpp(587) : (QgsMapRenderer::render) Rendering completed in (seconds): 0

By the way, the crash happens also if you have a GRASS raster in the legend and you close qgis (file -> close), regardless if the mapset is open or closed.

Today I am on Vista, so I tried to do some tests, but it is all difficult on windows. I have installed 'Debugging Tools for Windows' and symbol files (.pdb) for windows. Unfortunately I have no symbol files for qgis/gdal, where/how can I get them?

It is however possible to connect to running qgis process and get some limited call stack:

WARNING: Stack unwind information not available. Following frames may be wrong.
ntdll!RtlTryEnterCriticalSection+0x69
ntdll!RtlTryEnterCriticalSection+0x334
ntdll!RtlTryEnterCriticalSection+0x56f
kernel32!HeapFree+0x14
MSVCR71!free+0x39
gdal_GRASS!GDALNoDataMaskBand::operator=+0x3766
gdal_GRASS!GDALNoDataMaskBand::operator=+0x494c
gdal16!GDALClose+0x81
qgis!OGREnvelope::Merge+0x4558e
qgis_core!QgsVectorDataProvider::capabilities+0xa7750
qgis!OGREnvelope::Merge+0x20759d
qgis!OGREnvelope::Merge+0x207221
qgis!OGREnvelope::Merge+0x280d93
[[QtCore]]4!QMetaObject::activate+0x221
[[QtCore]]4!QMetaObject::activate+0x62
[[QtGui]]4!QAction::activate+0xae
[[QtGui]]4!QMenu::changeEvent+0x1161
[[QtGui]]4!QMenu::setId+0x5f5

It seems that the problem is in GDALNoDataMaskBand destruktor which is caling free on some wrong address.

#2028 is probably the same problem (on reloading map)

Can anything be done to solve/workaround this problem in the short term? I have to give a course at the end of the month and most of the attendees will have Vista/Seven... :(

I have the new provider mostly working, without support for groups and I have no idea if it works on windows.

If you think, that current trunk is stable enough for the course, I could commit that to trunk.

Hi Radim,
the first thing I notice is about linux.

After having compiled trunk, when I open the grass mapset in the qgis demo dataset and then I add the raster that is in there (gtopo30) qgis (the "value tool" plugin to be precise) throws the following

Traceback (most recent call last):
  File "/home/vania/.qgis//python/plugins/valuetool/valuewidget.py", line 134, in printValue
    self.ymin=min(self.ymin,cstr.minimumValue())
[[AttributeError]]: 'NoneType' object has no attribute 'minimumValue'

then qgis also throws this

Cannot query raster 
Cannot start module
command: /usr/share/qgis/grass/modules/qgis.g.info info=query rast=gtopo30@demo coor=-1.43995e+06,8.38359e+06<br><br>
GRASS_INFO_WARNING(5191,1): Reading raster map <gtopo30@demo> request for row -174 is outside region
GRASS_INFO_END(5191,1)

GRASS_INFO_ERROR(5191,2): Unable to read raster map <gtopo30@demo> row -174
GRASS_INFO_END(5191,2)

in both cases when passing the mouse over the raster in the canvas.

The happens under windows, but not immediately after having added the GRASS raster to the canvas. I'll be more precise in the notes that will follow this one.

Well...

the above messages show also under Xp and Vista, but it turns that depends if the "value tool" plugin is installed or not. If not, then no error/warning messages are shown.

I'm having an hard time finding a pattern about when the above messages do show and when not. An interesting finding is that if I create a mapset in wgs84 and then import some rasters and add them to the canvas then the messages do not show.

If I create a mapset in the same system of the one available in the qgis demo mapset (epsg 2964), import the "landcover.img" raster and the add it to the canvas, then the messages do show always (it happens also using directly the mapset available in the qgis demo dataset).

I tested to create a mapset in another reference system (epsg 32638) import a raster with the same projection and add it to the map. It seemed to me that the messages were showing, but now I can't reproduce... or maybe I'm just hallucinating (playing with 3 operating systems at one time is not a good practice for my brain).

Small rasters to do tests can be found here

https://trac.faunalia.it/GdalTools-plugin/wiki

Back to the original problem:

(under Vista) using the mapset in the qgis demo dataset I notice that if the the raster is added trough the qgis GRASS toolbar, then removing it from the legend do not causes a crash. If the same raster is added via the GRASS browser, then when removed from the legend qgis always crashes, even if you meanwhile close de mapset.

Seems to confirm no problems under xp.

Replying to [comment:17 lutra]:

After having compiled trunk, when I open the grass mapset in the qgis demo dataset and then I add the raster that is in there (gtopo30) qgis (the "value tool" plugin to be precise) throws the following

> Traceback (most recent call last):
>   File "/home/vania/.qgis//python/plugins/valuetool/valuewidget.py", line 134, in printValue
>     self.ymin=min(self.ymin,cstr.minimumValue())
> [[AttributeError]]: 'NoneType' object has no attribute 'minimumValue'

Isn't it bug in the plugin? Should not they check 'if cstr'? Where can I find the plugin?! I cannot find it on internet. The installer in QGIS is currently disabled. I have to see which values it reads and if they can be passed from the provider with current raster providers implementation.

Does it work with WMS layer?

then qgis also throws this

> Cannot query raster 
> Cannot start module
> command: /usr/share/qgis/grass/modules/qgis.g.info info=query rast=gtopo30@demo coor=-1.43995e+06,8.38359e+06<br><br>
> GRASS_INFO_WARNING(5191,1): Reading raster map <gtopo30@demo> request for row -174 is outside region
> GRASS_INFO_END(5191,1)
> 
> GRASS_INFO_ERROR(5191,2): Unable to read raster map <gtopo30@demo> row -174
> GRASS_INFO_END(5191,2)

in both cases when passing the mouse over the raster in the canvas.

I have fixed it in the module so that it returns null. It is also called by valuetool?
The provider method is called by QgsRasterLayer::identify and the results
map does not seem to be expected to contain any particular data, just readable info.

Replying to [comment:20 lutra]:

Back to the original problem:

(under Vista) using the mapset in the qgis demo dataset I notice that if the the raster is added trough the qgis GRASS toolbar, then removing it from the legend do not causes a crash. If the same raster is added via the GRASS browser, then when removed from the legend qgis always crashes, even if you meanwhile close de mapset.

I have commented this in another ticket, it is fixed, wait for the next build.

Replying to [comment:17 lutra]:

 Traceback (most recent call last):
   File "/home/vania/.qgis//python/plugins/valuetool/valuewidget.py", line 134, in printValue
     self.ymin=min(self.ymin,cstr.minimumValue())
 [[AttributeError]]: 'NoneType' object has no attribute 'minimumValue'

I have looked into the valuewidget.py, it is using layer.contrastEnhancement, but it knows nothing about providers. Current support for raster providers is just a hack for WMS. It cannot be fixed in GRASS raster provider.

I can only recommend you to dont use valuetool with GRASS rasters (and probably WMS).

Replying to [comment:21 rblazek]:

Isn't it bug in the plugin? Should not they check 'if cstr'? Where can I find the plugin?! I cannot find it on internet. The installer in QGIS is currently disabled. I have to see which values it reads and if they can be passed from the provider with current raster providers implementation.

Hi,
the "value tool" plugin is in the contributed repository, available among all the others. As far as I can remember it always worked fine with GRASS rasters. In fact it is one of that tools we use more when we reclassify rasters (and show how to), use r.mapcalc, etc.

Does it work with WMS layer?

as far as I know, no.

I have fixed it in the module so that it returns null. It is also called by valuetool?
The provider method is called by QgsRasterLayer::identify and the results
map does not seem to be expected to contain any particular data, just readable info.

You may want to ask this in the dev mailing list.

Replying to [comment:23 rblazek]:

It cannot be fixed in GRASS raster provider.

I can only recommend you to dont use valuetool with GRASS rasters (and probably WMS).

Hi just checked qgis 1.4 and the "value tool" plugin works fine with GRASS rasters. You may want also to give a look to the attached images.

With QGIS 1.4 I opened the GRASS mapset in the qgis sample dataset, loaded the raster (gtopo30) and changed its colormap with r.colors and closed the mapset.

Then I reopened the mapset and the rasters with qgis 1.5 and this is how it shows (plus the value tool error).

Tested under windows xp, but it should be the same also under linux.

[Sorry for bugging and flooding this ticket, just trying to be useful]

(see the attached image "Screenshot-1.png") I just found that the raster shows all scrambled only if added trough the qgis GRASS toolbar, If added from the GRASS browser it renders fine.

Replying to [comment:26 lutra]:

Screenshot-1.png

Nice, unfortunately i works for me both on ubuntu and xp.qgis.d.rast reads the raster row by row and for each cell prints to output BGRA (4 bytes) or ARGB (for big endian). QGIS reads everything and sets the QImage data with memcpy. It is a bit tricky, I used that way to get higher performance and well, also to enjoy it and get such a nice images. I could use idiotproof setPixel() but it would be too easy.

Does it displays always with the same colors or they are random?

You can tests qgis.d.rast directly from GRASS shell to see if the output is correct specifying window=xmin,ymin,xmax,ymax,ncols,nrows and pass it either to od, example:

/home/radim/apps/share/qgis/grass/modules/qgis.d.rast map=pok@demo window=-6.85857e+06,2.25129e+06,3.172e+06,7.79079e+06,10,10 | od -w40 -tx4

Then you can replace the qgis.d.rast with a script like this

#!/usr/bin/perl
for($i=0;$i<100000;$i=$i+1){
  printf "%c%c%c%c", 255, 0, 0, 255;
}

Size of integer and byte order could also be involved but I don't see how, I have checked that QImage is realy using uchar and the image size is correct.

Replying to [comment:27 rblazek]:

Hi, I updated to 4be3de4b (SVN r12892) and this are my first quick notes. I'll do the tests you suggest tomorrow. I haven't read your answers with attention so please forgive me if I'm repeating something is already known/obvious.

Does it displays always with the same colors or they are random?

always the same.

First a good news, removing the rasters form the legend under Vista does not crash qgis anymore. So... probably the problem that originated this ticket is really fixed.

Nevertheless there are side effects that I'll report here even if they are more about #2028 and #2078. Tomorrow I'll copy the notes also to the respective tickets.

Then:

a) On both XP and Vista when I import (v.in) the following raster (single band)

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

qgis always renders the image with the colors scrambled.

b) On both XP and Vista when I import (v.in) the following raster (multi band)

http://www.faunalia.it/qgis/data/landsat-mosaic-test.zip

qgis renders the image fine.

c) The raster (single band) in the mapset in the qgis sample dataset is rendered fine on both xp and Vista

d) in all cases a) b) and c) if the "value tool" pluign is active it returns a python error. It used to work with GRASS rasters.

e) On both XP and Vista, when applying a r.colors rule on b) it works fine and it refreshes correctly. When applying a r.colors rule on c) it renders with colors scrambled.

Could this mean that there is a problem with single band images?

Replying to [comment:28 lutra]:

a) On both XP and Vista when I import (v.in) the following raster (single band)
http://www.faunalia.it/qgis/data/srtm30-relief.zip
qgis always renders the image with the colors scrambled.
b) On both XP and Vista when I import (v.in) the following raster (multi band)
http://www.faunalia.it/qgis/data/landsat-mosaic-test.zip
qgis renders the image fine.

I dont see any obvious difference which could cause it, apart there are 2 rules in CT for srtm30.
Its on you to find the difference causing the problem. Try various CT, pieces of raster etc.
And please test first if it renders well in pure GRASS! Such a test should always be done before an error is reported for QGIS!

d) in all cases a) b) and c) if the "value tool" pluign is active it returns a python error. It used to work with GRASS rasters.

Please DON'T report the problems with valuetool here. I have explained why the problem cannot be fixed in GRASS provider. You can fill a ticket for enhancement of raster providers infrastructure. You can fix the valuetool to use only raster layer identify().

Just a note about tools like that, in the new GRASS provider I have followed GRASS philosophy to access GRASS data via modules, and that means everywhere identify() is called the GRASS module is run. That means, if you have a tool like valuetool and you move to mouse over QGIS canvas the GRASS module shoudl be called for each pixel, e.i. hundreds / thousands of time. Isn't nice?!

e) On both XP and Vista, when applying a r.colors rule on b) it works fine and it refreshes correctly. When applying a r.colors rule on c) it renders with colors scrambled.
Could this mean that there is a problem with single band images?

What do you mean by single band and multi band? GRASS rasters are always single band.

Replying to [comment:29 rblazek]:

Its on you to find the difference causing the problem. Try various CT, pieces of raster etc.
And please test first if it renders well in pure GRASS! Such a test should always be done before an error is reported for QGIS!

For what I see is just a visualization/render problem in qgis trunk, not in qgis 1.4 or GRASS osgeo4w (tested both before commenting). Have a look to the small test described below (use the attached "ancc6_geo.dem").

• Import "ancc6_geo.dem" in a mapset with in qgis 1.4 or with GRASS, add it to the canvas and then it will render fine. Open the mapset in qgis trunk, add it to the canvas and it will render wrong.

• You can also test otherwise. Import "ancc6_geo.dem" in qgis trunk, add it to the canvas and it will render wrong. Then open the mapset in qgis 1.4 or GRASS, add it to the canvas and it will render fine.

The bottom line seems to be the fact that in qgis trunk there are cases (always?) where the GRASS raster is added with the "wrong colorbands".

See attached image "colorbands.png", and make a test using "ancc6_geo.dem":

• create a project in qgis 1.4 and import in a mapset the raster "ancc6_geo.dem". Add it to the canvas. In the raster properties it will show as "single band gray". Save the project (leave the GRASS raster in the canvas/legend).

• open the project in qgis trunk: the GRASS raster renders fine (and guess what, no "value tool" plugin errors). Now add it again from the GRASS toolabr or from the GRASS browser: it will render wrong. Open the raster properties and it will show as "three band color", but color bands are not set. Save the project (leave in the legend/canvas both the same raster added in 1.4 and trunk).

• open again the project in qgis 1.4, the raster added in qgis trunk will not even show in the legend/canvas.

I believe this is the key of the problem.

Please DON'T report the problems with valuetool here. I have explained why the problem cannot be fixed in GRASS provider. You can fill a ticket for enhancement of raster providers infrastructure. You can fix the valuetool to use only raster layer identify().

Please don't get it wrong, I'm just noticing about the side effects of the new provider. In any case see the above test, it seems to me that it proves there is a problem in the provider when a GRASS raster is added into the canvas. Solve this also the plugin problem will be gone.

What do you mean by single band and multi band? GRASS rasters are always single band.

forget about this and just consider the above steps to reproduce the problem. I thought to have found a pattern about the type of rasters to be imported into GRASS, but I was wrong.

Replying to [comment:30 lutra]:

• Import "ancc6_geo.dem" ...

Why are you using a different demo data in each comment, please choose one and use it always.

Forget about 1.4., obviously if a raster is stored with certain provider in project it is reloaded with the same even in different qgis version.

Most probably the problem is stdout in text mode on windows and occasional convertion of \
to \
\
, I have submitted a fix, we will see tomorrow.

Replying to [comment:31 rblazek]:

Why are you using a different demo data in each comment, please choose one and use it always.

sorry, I thought you asked me to test other rasters.

Forget about 1.4., obviously if a raster is stored with certain provider in project it is reloaded with the same even in different qgis version.

right, that was a stupid comment.

Most probably the problem is stdout in text mode on windows and occasional convertion of \

Attention! all I commented in comment # 30 is true also under Linux!

Moreover I compiled now qgis with your latest patch and as far I can see the situation is getting better (colors are not scrambled) but in the qgis raster properties the colorbands are still not defined (and this still causes the value tool error, forgive me). See attached image.

Hi Radim,

I just compiled 09547004 (SVN r12918) under linux and I still see the colorbands problem (see the last attached image).

I also noticed another thing that may found interesting:

in qgis trunk (not in 1.4) when using the identify tool on a cell of a GRASS raster that has a NULL value, then the value -2147483648 is shown instead.

I would also underline that your new driver has solved a nasty bug related to GRASS rasters under windows that passed unnoticed until today:

open a mapset and add a GRASS raster (in qgis 1.4)

use the identify tool/ruler/etc.

close the mapset

pass the tool over the map canvas

a warning is issued saying that the mapset is not defined

at this stage if you try to exit QGIS the program will crash

The actual problem with GRASS rasters has nothing to do with the original ticket, do you want me to open a new one?

Replying to [comment:33 lutra]:

I just compiled 09547004 (SVN r12918) under linux and I still see the colorbands problem (see the last attached image).

Forget about color bands, they have no meaning for GRASS.

in qgis trunk (not in 1.4) when using the identify tool on a cell of a GRASS raster that has a NULL value, then the value -2147483648 is shown instead.

Fixed.

With stdout set to bin mode rendering no works OK also on windows.

Replying to [comment:34 rblazek]:

Forget about color bands, they have no meaning for GRASS.

You are right.

I still see two issues (sorry):

+) (see attached image) When I double click a GRASS raster in the legend the properties window open but the only three tabs show and a few options are greyed. If you then double click a non GRASS raster, close the dialog and double click the GRASS raster again, the properties dialog shows correctly.

But if you uncheck the GRASS raster from the legend, when you double click it you'll see again the wrong dialog window

+) making GRASS raster pixels transparent (properties -> transparency) does not work anymore. Please notice that with the new provider, before being able to define transparent pixels for GRASS rasters you will have always to manually change (in the "symbology" tab) from "three band color" to "grayscale", otherwise you'll not be able to define the transparency for the "indexed value" (or "gray" if in greyscale).

I believe that with this new provider a few changes need to be made in the properties dialog for GRASS rasters.

Hi Radim,
about the problems in my last comment I opened a new ticket, so this can be abandoned.