Bug report #1480

Strange behavior of set default qml style for indexed rasters

Added by Maxim Dubinin almost 15 years ago. Updated over 14 years ago.

Assignee:ersts -
Affected QGIS version: Regression?:No
Operating System:All Easy fix?:No
Pull Request or Patch supplied: Resolution:fixed
Crashes QGIS or corrupts data: Copied to github as #:11540


- Load indexed raster
- Open properties
- Color table
- Change a couple of colors
- Save as default
- Ok
- Try to load the same raster or remove it and try to load it

Is it either not loaded (win) or crashes QGIS (linux)

tested on this raster: http://gis-lab.info/other/indexed-raster-topo1km.7z


#1 Updated by ersts - almost 15 years ago

  • Status changed from Open to In Progress

I actually see several problems and I am surprised they have not come up before...

Part of the back trace:

#0  0xb6d0a845 in GDALClose () from /usr/lib/libgdal1.5.0.so.1
#3905  0xb7f48de7 in ~QgsRasterLayer (this=0x9a6e1d0) at 
#3906  0x080e988e in [[QgisApp]]::addRasterLayer (this=0x96b8f80, theRasterLayer=0x9a6e1d0) at
#3907  0x080e9aca in [[QgisApp]]::addRasterLayers (this=0x96b8f80, theFileNameQStringList=@0xbfcb86b8,
 guiWarning=true) at /home/pete/devel/qgis/trunk-debug/src/app/qgisapp.cpp:5306
#3908  0x080f2d19 in [[QgisApp]]::addRasterLayer (this=0x96b8f80) at 

First issue is that the load default styles call is being made before a raster layer is actually loaded and set_blah_BandName( ) makes a call to validateBandName() which check to see if the band name actually exists, but since a raster layer has not yet be loaded all validation requests will fail and any/all bands will be set to "Not Set", but that is not what causes the crash.

Second problem and a more important one is that the load default styles is returning false, which makes the constructor abort mid way, again before a valid layer is loaded. The loading of the raster layer is where the "isValid" variable gets set, which is not initialized before hand. So when default styles kicks back to the qgisapp.cpp around line 5107 is check to see if the raster layer is valid, if not the raster layer is delete. Because the variable is not initialized,sometime it is true and sometimes it is false which could explain why it sometimes crashes and sometimes does not. But the actual crash is the third problem.

The Third problem is that the in the deconstructor GDALClose is being called on the wrong pointer, which is not checked to see if it is null. This is what actually causes the crash, because if the raster layer has not been loaded, it going to be null.

Sorry for the long post, it is partially to help remember at a later date. I am sure there is going to be a quick release of small bug fixes shortly after v1.0.0 is released.

#2 Updated by John Tull almost 15 years ago

This seems to also occur if setting raster transparency only and saving as a default.

#3 Updated by ersts - almost 15 years ago

  • Resolution set to fixed
  • Status changed from In Progress to Closed

I will let this sit in trunk for a couple of days before shifting over to the Vesion-1_0 branch so a little more testing can be done

#4 Updated by Anonymous over 14 years ago

Milestone Version 1.0.1 deleted

Also available in: Atom PDF