gdalwarp hangs indefinitely for extremely small inputs

[perh]

We use gdalwarp in an automated workflow that takes customer data, of varying quality, as input. A few days ago we discovered that gdalwarp hangs indefinitely on a specific GeoTIFF that seems technically correct/well-formed, except that it is a single pixel. Running with debug logging on, the last few lines printed before it hangs forever is:

OGRCT: Wrap source at 153.024.
OGRCT: Source: +proj=longlat +ellps=WGS84 +no_defs
OGRCT: Target: +proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +no_defs
OGRCT: Wrap target at 153.024.
OGRCT: Source: +proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +no_defs
OGRCT: Target: +proj=longlat +ellps=WGS84 +no_defs
GDAL: GDAL_CACHEMAX = 398 MB
GDAL: GDALWarpKernel()::GWKAverageOrMode()
Src=0,0,1x1 Dst=0,0,1x1
0WARP: Using 0 threads

This is with -wo NUM_THREADS=ALL_CPUS; other settings (0, 1, ... or not set at all) works. I agree that for practical purposes, a 1x1-pixel image is probably not that useful but I had expected gdalwarp to either cleanly accept or reject any input, rather than hang, which is why I have submitted this as a defect.

[Even Rouault]

In 40075:

Warper: avoid blocking when number of rows is 1 and NUM_THREADS > 1 (fixes #7041). Also limit the number of threads so that each one processes at least 65536 pixels

[Even Rouault]

In 40076:

Warper: avoid blocking when number of rows is 1 and NUM_THREADS > 1 (fixes #7041). Also limit the number of threads so that each one processes at least 65536 pixels

[Even Rouault]

In 40077:

Warper: avoid blocking when number of rows is 1 and NUM_THREADS > 1 (fixes #7041). Also limit the number of threads so that each one processes at least 65536 pixels

[Even Rouault]

Thanks for the report

Note: I could also reproduce with -wo NUM_THREADS=x with x>=2

[perh]

Thank you, Even. Looking forward to next release!