[Bug] r.fill.dir (main) fails with "ERROR: File read/write operation failed: Invalid argument (22)"

[dhdeangelis]

Describe the bug

r.fill.dir (main) fails with "ERROR: File read/write operation failed: Invalid argument (22)", while r.fill.dir (8.4.1) does not fail and produces valid results.
Possibly related to #5783

To reproduce

1. given a DEM 'dem'
2. run: 'r.fill.dir input=dem output=demFilled direction=demDir areas=demAreas'
3. See error

Expected behavior

In this particular case, I expect r.fill.dir should give valid results. If for whatever reason the input data is not considered valid, I expect error messages to be more explicit and clear.

System description

• Operating System: Linux, openSUSE Tumbleweed

• GRASS version: 8.4.1 (OK), main (e6e1024) failing

• details about further software components

g.version -rge
version=8.5.0dev
date=2025
revision=e6e10249c4
build_date=2025-11-21
build_platform=x86_64-pc-linux-gnu
build_off_t_size=8
libgis_revision=85b38da2a3
libgis_date=2025-10-17T14:54:12+00:00
proj=9.8.0
gdal=3.13.0dev-3ccaf135cf-dirty
geos=3.15.0dev
sqlite=3.50.4

python3 -c "import sys, wx; print(sys.version); print(wx.version())"
3.13.9 (main, Nov 15 2025, 21:56:21) [GCC]
4.2.3 gtk3 (phoenix) wxWidgets 3.2.8

[nilason]

Thanks for the report!

I managed to reproduce with example from r.fill.dir manual. Here is where the error is triggered:

grass/raster/r.fill.dir/tinf.c

Line 404 in c89398e

if (lseek(fh, (off_t)-2 * bnd->sz, SEEK_CUR) == -1) {

Actually, the error message added with #5783 is very informative, and adding the error check to this place in 8.4.3dev the same error occurred. So this bug has been silently been overlooked.

[nilason]

The problem could be that lseek is attempting a rewind, but if being at the end of the file SEEK_CUR cannot be used:

grass/raster/r.fill.dir/tinf.c

Lines 403 to 404 in c89398e

	rc = read(fh, bnd->b[0], bnd->sz);
	if (lseek(fh, (off_t)-2 * bnd->sz, SEEK_CUR) == -1) {

@metzm Maybe you might have an idea?

[metzm]

Good catch! There is an error in the logic calling retreat_band3(). The reason for the error is that the current file offset is only at bnd->sz but lseek should go back by -2 * bnd->sz which is before the beginning of the file.

Either at some stage retreat_band3() is called too often or there is a more serious error in the logic of the module. This needs more debugging.

[nilason]

This particular (flawed) lseek line seems to have been there since its introduction, but was never detected as the return value wasn't checked. Maybe this was worked around elsewhere in code? A lot of possibilities...

[metzm]

A solution to keep the current results (they may be wrong because of this failed backward lseek() would be to not lseek() back if the requested negative offset would result seeking before the beginning of the file.

A better solution would be to check if retreat_band3() is used properly to calculate correct results.

[metzm]

The error is triggered here when i reaches 1. File offset is then set to the beginning of the file here. Reading one line (the first line for i = 1), then trying to go back by two lines obviously does not work. Unfortunately, the code is free of any comments, so there is no explanation for the for loop for (i = nl - 2; i >= 1; i -= 1) { which causes this error.

[metzm]

Changing the iteration in the for loop for (i = nl - 2; i >= 1; i -= 1) { to for (i = nl - 1; i > 1; i -= 1) { avoids this error and provides results identical to GRASS84. Test command with the NC dataset:

r.fill.dir input=elev_state_500m output=demFilled_84 direction=demDir_84 areas=demAreas_84