[QGIS-trac] Re: [Quantum GIS] #2028: [Vista] GRASS plugin crashes
QGIS when running the r.colors, r.null, v.dissolve modules
Quantum GIS
qgis at qgis.org
Mon Jan 11 15:11:05 EST 2010
#2028: [Vista] GRASS plugin crashes QGIS when running the r.colors, r.null,
v.dissolve modules
--------------------------------------------------------------+-------------
Reporter: pcav | Owner: rugginoso
Type: bug | Status: new
Priority: critical: causes crash or data corruption | Milestone: Version 1.5.0
Component: GRASS | Version: HEAD
Resolution: | Keywords:
Platform_version: | Platform: Windows
Must_fix: No | Status_info: 0
--------------------------------------------------------------+-------------
Comment (by 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.
--
Ticket URL: <http://trac.osgeo.org/qgis/ticket/2028#comment:13>
Quantum GIS <http://qgis.org>
Quantum GIS is an Open Source GIS viewer/editor supporting OGR, PostGIS, and GRASS formats
More information about the QGIS-trac
mailing list