gdal_fillnodata.py segmentation fault when using --si smooth_iterations

[torse]

Expected behavior and actual behavior.

The following command fails with a segmentation fault at least for version 2.3.2 and 2.4.0 on the attached file:

$ gdal_fillnodata.py --version
GDAL 2.4.0, released 2018/12/14
$ gdal_fillnodata.py -md 5 -si 10 fillsegfault.tif /tmp/temp.tif
0...10...20...30...40...50...60...70...80...90Segmentation fault

Commands works correctly when using GDAL 2.2.4 or without --si parameter:

$ gdal_fillnodata.py --version
GDAL 2.4.0, released 2018/12/14
$ gdal_fillnodata.py -md 5 fillsegfault.tif /tmp/temp.tif
0...10...20...30...40...50...60...70...80...90...100 - done.

$ gdal_fillnodata.py --version
GDAL 2.2.4, released 2018/03/19
$ gdal_fillnodata.py -md 5 -si 10 fillsegfault.tif /tmp/temp.tif
0...10...20...30...40...50...60...70...80...90...100 - done.

Steps to reproduce the problem.

Extract attached fillsegfault.zip and run gdal_fillnodata on the geotiff :

$ gdal_fillnodata.py -md 5 -si 10 fillsegfault.tif /tmp/temp.tif
0...10...20...30...40...50...60...70...80...90Segmentation fault

Operating system

CentOS 7

GDAL version and provenance

2.2.4, 2.3.2 and 2.4.0 version from source (compiled on CentOS 7 with gcc version 4.8.5 20150623 (Red Hat 4.8.5-16) (GCC) )

[torse]

Debug backtrace:

without -si:

$ gdb python
GNU gdb (Ubuntu 8.1-0ubuntu3) 8.1.0.20180409-git
..
(gdb) run /local/lib/gdal-2.4.0/bin/gdal_fillnodata.py -md 5 /local/data/issues/gdalfillsegfault/fillsegfault.tif /tmp/temp.tif

Starting program: /local/lib/Python-3.6.4/bin/python /local/lib/gdal-2.4.0/bin/gdal_fillnodata.py -md 5 /local/data/issues/gdalfillsegfault/fillsegfault.tif /tmp/temp.tif

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0...10...20...30...40...50...60...70...80...90...100 - done.
[Inferior 1 (process 21250) exited normally]

with -si:

$ gdb python
GNU gdb (Ubuntu 8.1-0ubuntu3) 8.1.0.20180409-git
..
(gdb) run /local/lib/gdal-2.4.0/bin/gdal_fillnodata.py -md 5 -si 10 /local/data/issues/gdalfillsegfault/fillsegfault.tif /tmp/temp.tif

Starting program: /local/lib/Python-3.6.4/bin/python /local/lib/gdal-2.4.0/bin/gdal_fillnodata.py -md 5 -si 10 /local/data/issues/gdalfillsegfault/fillsegfault.tif /tmp/temp.tif

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0...10...20...30...40...50...60...70...80...90
Program received signal SIGSEGV, Segmentation fault.

0x00007fffee38a92b in PyProgressProxy (dfComplete=0.90000000000000002, pszMessage=0x7fffedd4eda2 "Smoothing Filter...", pData=0x0) at extensions/gdal_wrap.cpp:3700
3700	extensions/gdal_wrap.cpp: No such file or directory.

[duckontheweb]

I'm seeing this behavior as well on both Ubuntu 18.04 and Mac OSX. On my Mac I also get an alert that Python has unexpectedly shut down.

[jratike80]

It seemed to work with OSGeo4W version on Windows (GDAL 2.4.0, Python 2.7.14) because no error was printed but actually it did not. Process stops at 90% and the resulting image "fill2.tif" contains just zeroes. The debug info from console:

GDAL: GDALOpen(fillsegfault.tif, this=0000000000EE38B0) succeeds as GTiff.
GDAL: QuietDelete(fill2.tif) invoking Delete()
GDAL: GDALOpen(fill2.tif, this=0000000000EF29D0) succeeds as GTiff.
GDAL: GDALDefaultOverviews::OverviewScan()
MDReaderPleiades: Not a Pleiades product
MDReaderPleiades: Not a Pleiades product
GDAL: GDALClose(fill2.tif, this=0000000000EF29D0)
GDAL: GDALDriver::Create(GTiff,fill2.tif,1200,1200,1,Byte,0000000000000000)
GDAL: GDAL_CACHEMAX = 813 MB
0GDAL: GDALDriver::Create(GTiff,C:\TEMP\_17820_1fill_y_work.tif,1200,1200,1,UInt16,0000000000F002D0)
GDAL: GDALDriver::Create(GTiff,C:\TEMP\_17820_1fill_val_work.tif,1200,1200,1,Byte,0000000000F002D0)
GDAL: GDALDriver::Create(GTiff,C:\TEMP\_17820_1fill_filtmask_work.tif,1200,1200,1,Byte,0000000000F002D0)
...10...20...30...40...50...60...70...80...90

Without -si the debug info shows much more activity

GDAL: GDALOpen(fillsegfault.tif, this=0000000000880550) succeeds as GTiff.
GDAL: GDALDriver::Create(GTiff,fill3.tif,1200,1200,1,Byte,0000000000000000)
GDAL: GDAL_CACHEMAX = 813 MB
0GDAL: GDALDriver::Create(GTiff,C:\TEMP\_11876_1fill_y_work.tif,1200,1200,1,UInt16,000000000088B6B0)
GDAL: GDALDriver::Create(GTiff,C:\TEMP\_11876_1fill_val_work.tif,1200,1200,1,Byte,000000000088B6B0)
GDAL: GDALDriver::Create(GTiff,C:\TEMP\_11876_1fill_filtmask_work.tif,1200,1200,1,Byte,000000000088B6B0)
...10...20...30...40...50...60...70...80...90...100 - done.
GDAL: GDALClose(C:\TEMP\_11876_1fill_y_work.tif, this=0000000003D32C20)
GDAL: GDALClose(C:\TEMP\_11876_1fill_val_work.tif, this=0000000003D435A0)
GDAL: GDALClose(C:\TEMP\_11876_1fill_filtmask_work.tif, this=0000000003D53DF0)
GDAL: GDALOpen(C:\TEMP\_11876_1fill_y_work.tif, this=00000000008BEB60) succeeds as GTiff.
GDAL: GDALDefaultOverviews::OverviewScan()
MDReaderPleiades: Not a Pleiades product
MDReaderPleiades: Not a Pleiades product
GDAL: GDALClose(C:\TEMP\_11876_1fill_y_work.tif, this=00000000008BEB60)
GDAL: GDALOpen(C:\TEMP\_11876_1fill_val_work.tif, this=00000000040F0080) succeeds as GTiff.
GDAL: GDALDefaultOverviews::OverviewScan()
MDReaderPleiades: Not a Pleiades product
MDReaderPleiades: Not a Pleiades product
GDAL: GDALClose(C:\TEMP\_11876_1fill_val_work.tif, this=00000000040F0080)
GDAL: GDALOpen(C:\TEMP\_11876_1fill_filtmask_work.tif, this=00000000008BE750) succeeds as GTiff.
GDAL: GDALDefaultOverviews::OverviewScan()
MDReaderPleiades: Not a Pleiades product
MDReaderPleiades: Not a Pleiades product
GDAL: GDALClose(C:\TEMP\_11876_1fill_filtmask_work.tif, this=00000000008BE750)
GDAL: GDALClose(fillsegfault.tif, this=0000000000880550)
GDAL: GDALClose(fill3.tif, this=0000000000884790)
GDAL: In GDALDestroy - unloading GDAL shared library.

[AndrewAnnex]

I get this issue on macOS and ubuntu...