Bug report #19760
Raster calculator crashes QGIS 3
Status: | Closed | ||
---|---|---|---|
Priority: | High | ||
Assignee: | Alessandro Pasotti | ||
Category: | Raster Calculator | ||
Affected QGIS version: | 3.2.2 | Regression?: | No |
Operating System: | Win10 | Easy fix?: | No |
Pull Request or Patch supplied: | No | Resolution: | |
Crashes QGIS or corrupts data: | Yes | Copied to github as #: | 27585 |
Description
I am trying to use the raster calculator and QGIS crashes when I compute a simple raster subtraction. These files are in the same coordinate system, same processing area, same scale, etc. They are a little over 400MB each, but my machine can handle this little processing. Any ideas? Below is the bug report.
Thanks!
User Feedback¶
Report Details¶
Crash ID: 82ea1fdd86be5198d4c4b5e19a77c8b580ba2ec7
Stack Trace
memcpy : GDALRasterBand::IRasterIO : GDALRegister_GTiff : GDALRasterBand::RasterIO : GDALWarpOperation::operator= : GDALWarpOperation::operator= : QgsRasterCalculator::processCalculation : QgisApp::showRasterCalculator : QMetaObject::activate : QAction::activate : QMenu::actionGeometry : QMenu::actionGeometry : QMenu::mouseReleaseEvent : QWidget::event : QMenu::event : QApplicationPrivate::notify_helper : QApplication::notify : QgsApplication::notify : QCoreApplication::notifyInternal2 : QApplicationPrivate::sendMouseEvent : QSizePolicy::QSizePolicy : QSizePolicy::QSizePolicy : QApplicationPrivate::notify_helper : QApplication::notify : QgsApplication::notify : QCoreApplication::notifyInternal2 : QGuiApplicationPrivate::processMouseEvent : QWindowSystemInterface::sendWindowSystemEvents : QEventDispatcherWin32::processEvents : CallWindowProcW : DispatchMessageW : QEventDispatcherWin32::processEvents : qt_plugin_query_metadata : QEventLoop::exec : QCoreApplication::exec : main : BaseThreadInitThunk : RtlUserThreadStart :
QGIS Info
QGIS Version: 3.2.2-Bonn
QGIS code revision: 26842169e9
Compiled against Qt: 5.9.2
Running against Qt: 5.9.2
Compiled against GDAL: 2.2.4
Running against GDAL: 2.2.4
System Info
CPU Type: x86_64
Kernel Type: winnt
Kernel Version: 10.0.17134
Associated revisions
[gdal] Fix an int overflow issue with raster block read
Fixes #19760 - Raster calculator crashes QGIS 3
.. and probably more, but this is one of the greediest
piece of code because it reads the whole raster to memory.
[gdal] Fix an int overflow issue with raster block read
Fixes #19760 - Raster calculator crashes QGIS 3
.. and probably more, but this is one of the greediest
piece of code because it reads the whole raster to memory.
cherry-picking commit da5a171
History
#1 Updated by Giovanni Manghi about 6 years ago
- Status changed from Open to Feedback
- Priority changed from Normal to High
Can you share the datasets? and to be clear, is the native QGIS raster calculator (now in the Processing toolbox) or else (i.e. the GDAL one)?
#2 Updated by Alessandro Pasotti about 6 years ago
I might be wrong but from the stacktrace it looks like a memory allocation error in memcpy, are you sure you are not running out of RAM?
#3 Updated by Giovanni Manghi about 6 years ago
Alessandro Pasotti wrote:
I might be wrong but from the stacktrace it looks like a memory allocation error in memcpy, are you sure you are not running out of RAM?
the "old" raster calculator (2.* implementation, not in processing) was known to eat all memory with large rasters, probably is the same issue.
#4 Updated by Giovanni Manghi about 6 years ago
Please try on QGIS 3.4.1, if the issue is still valid change the affected version, thanks.
#5 Updated by Alessandro Pasotti almost 6 years ago
- Assignee set to Alessandro Pasotti
#6 Updated by Alessandro Pasotti almost 6 years ago
- Status changed from Feedback to In Progress
I can confirm that memcpy is to blame and a int type overflow is probably the root of the problem.
#7 Updated by Anonymous almost 6 years ago
- Status changed from In Progress to Closed
- % Done changed from 0 to 100
Applied in changeset qgis|da5a171377681747a23b0daf4776532cf69c3950.
#8 Updated by Giovanni Manghi almost 6 years ago
Thanks Alessandro for tackling this, it was MUCH needed.