Python stopped working when using python gdal_calc and band.ReadAsArray() on Windows

[miro]

I hope I am reporting this in the right place. When using gdal_calc on Windows in OSGeo4W_Shell or whenever using python from the OSGeo4W package it ends up with "Python.exe has stopped working" message where except of that message everything works on 100% - results are as it should be. Also when in python reading raster into array (band.ReadAsArray()) causes the same thing:

src_ds = gdal.Open(file_name) 
band = src_ds.GetRasterBand(1)    
in_array = band.ReadAsArray()

Again, except error message all works just fine. The same reported on stackexchange by somebody else: ​http://gis.stackexchange.com/questions/101921/gdal-calc-works-but-i-get-a-python-error-at-the-end-of-each-process-that-prevent

The answer "disable the crash dialogs in Windows using the DontShowUI" works for me but still...

[akaginch]

See also ​http://gis.stackexchange.com/questions/145124/gdal-calc-works-but-i-get-a-pyhon-error-at-the-end-of-each-process

[mcserep]

I would like to confirm that this is still an issue and not only with gdal_calc, but also with other python tools like gdal_merge and gdal2tiles.

Everything installed by OSGeo4W64 package manager,

• GDAL version: 2.0.2
• Python version: 2.7.5

I reproduced this issue on multiple computers with the following operating systems:

• Windows 7 x64
• Windows 8 x64
• Windows 10 x64

This problem restricts writing scripts around these GDAL tools and disabling crash dialogs is just a nasty workaround, not a real solution.

[miro]

GDAL 2.1.0, released 2016/04/25

Python 2.7.5 (default, May 15 2013, 22:44:16) [MSC v.1500 64 bit (AMD64)] on win 32

Error still persist. It is becoming more and more annoying for me because my colleagues started to use my scripts and I have to explain that scripts are working fine and the error message is fine and they just have to close that window all the time unless they want to play with registry keys...

[Titsl]

It would be nice if there would be some kind of response from GDAL on this issue, as it makes running batch files with these functions impossible. Several tickets with similar issues remain unsolved.

[jef]

Apparently happens when the garbage collector is running as

import gc
gc.disable()

avoids the crash.

[Titsl]

Replying to jef:

Apparently happens when the garbage collector is running as

import gc
gc.disable()

avoids the crash.

Thanks for the tip! I included it in the script, but it does not change anything. Python still crashes.

[ascarth]

This seems to be an issue with how GDAL has been built for OSGeo4W, or the Python version, but not with GDAL itself. I have found that python will crash using the OSGeo4W Shell, but not when using GDAL installed through ​Conda. Both installations are using GDAL 2.1.0. The only other difference is that Conda uses Python 2.7.12 and OSGeo4W uses Python 2.7.5

[mcserep]

Replying to ascarth:

This seems to be an issue with how GDAL has been built for OSGeo4W, or the Python version, but not with GDAL itself. I have found that python will crash using the OSGeo4W Shell, but not when using GDAL installed through ​Conda. Both installations are using GDAL 2.1.0. The only other difference is that Conda uses Python 2.7.12 and OSGeo4W uses Python 2.7.5

Since this is the website of OSGeo4W, I think this is still a valid and urgent bug report, and it is really disappointing how it lacks the required attention. By the way I faced the same bug when I used the GDAL binaries from ​GISInternals.

[rouault]

The issue can be more simply reproduced when just doing "from osgeo import gdalnumeric" and exiting the Python console.

This doesn't look like a fundamental flow of GDAL on Windows, since when using miniconda, or when building myself GDAL (with VS 2010 express, 64 bit), I don't have this issue.

For the record, my build recipee for the python bindings

• install Python 2.7.12 64bit
• pip install numpy ==> install numpy 1.11.2
• set DISTUTILS_USE_SDK=1
• set MSSdk=1
• cd gdal/swig/python
• python setup.py build

[jef]

Please recheck with GDAL 2.2

[ascarth]

Replying to jef:

Please recheck with GDAL 2.2

Hi jef. I have tested QGIS 2.18.8 and 2.14.15 (both built with GDAL 2.2.0) and neither experience the problem described above.

[jef]

Thanks

[rldhont]

I have just tested with QGIS 2.18.9 and the error message still remain.

[jef]

python bin\gdal_calc.py crashes for me only using python 2 on 64bit. It works (ie. shows the help message) with python3 and for both on 32bit.

[jef]

Updated swig (2.0.10 => 3.0.21) and rebuilt.

[rldhont]

Hi @jef, I have tested with QGIS 2.18.10 and the error still remains.

Do you have updated Swig ? Thanks for your time on this issue.

[jef]

Replying to rldhont:

Hi @jef, I have tested with QGIS 2.18.10 and the error still remains.

Do you have updated Swig?

yes. see comment:15

[Pieter Roggemans]

Same problem here... I don't find a "subscribe" button so I hope I'll receive notifications of updates if I add a comment...

[andek714]

Same problem here with gdal_merge.py from QGIS 2.18.4. Doesn't happen with ReadAsArray commented out and the problem is highly intermittent.

Didn't understand the comment about swig though, is it fixed by updating swig? And if so, how does one update swig in the osgeo4w installation?

[jef]

Fixed in gdal 2.2.1-2 (​GDAL r39813)

[andek714]

Sounds great! How do I get hold of this new gdal 2.2.1-2 release? Will it be part of an upcoming osgeo4w release and how do I install it in the meantime?

[jef]

Just run the installer and update.

[andek714]

Sorry, didn't realize it was already in the latest installer - had some problems updating my existing installation but now it works like a charm - THANKS!

[rouault]

Thanks Jef for finally figuring that out ! Backported to GDAL 2.2 branch per ​https://trac.osgeo.org/gdal/changeset/39834

[rldhont]

Hi, does the QGIS Windows standalone installers have been updated ?

[jef]

only on qgis point release - so yes.