Skip to content

Memory guard for geodesic slope/aspect #1283

@brendancol

Description

@brendancol

The geodesic method in slope() and aspect() allocates a (3, H, W) float64 stacked array (data, lat, lon) per call with no memory guard. A large enough lat/lon-tagged raster passed to slope(method='geodesic') or aspect(method='geodesic') will OOM the process.

A 50000x50000 float64 raster makes a ~30 GB stacked buffer before padding or output is allocated. The numpy, cupy, and dask paths in xrspatial/slope.py and xrspatial/aspect.py all do this.

Other modules in this repo already guard against the same shape of problem: dasymetric (#1263), cost_distance (#1264), morphology (#1258), glcm_texture (#1259).

Proposed fix: add a _check_geodesic_memory(rows, cols, func_name) helper in xrspatial/geodesic.py, modeled on _check_kernel_memory in xrspatial/morphology.py. Raise MemoryError when the stacked float64 buffer plus the float32 output plus a padding allowance exceeds 50% of available RAM. Call it from the geodesic branch of slope() and aspect() before dispatch.

Severity: HIGH. DoS vector, no existing guard.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workinghigh-priorityinput-validationInput validation and error messagesoomOut-of-memory risk with large datasets

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions