Skip to content

Memory guard for geodesic slope/aspect #1283

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.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

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