Skip to content

Reject oversize bump output rasters before allocation (#1231)#1234

Merged
brendancol merged 4 commits into
masterfrom
issue-1231
Apr 23, 2026
Merged

Reject oversize bump output rasters before allocation (#1231)#1234
brendancol merged 4 commits into
masterfrom
issue-1231

Conversation

@brendancol
Copy link
Copy Markdown
Contributor

Summary

  • _finish_bump allocated np.zeros((height, width)) with no memory check. The count guard added in bump: uint16 overflow, unbounded default count, and closure serialization OOM #1206 only covered the locs/heights arrays, so bump(width=1_000_000, height=1_000_000) slipped through (count capped at 10M ~ 160 MB) and then tried to allocate ~8 TB for the output raster.
  • Extended the memory budget check to include raster_bytes = w * h * 8 when the backend will materialize the full array. Dask paths build output lazily per-chunk, so they are excluded from the raster guard and keep handling large dimensions.
  • Added regression tests for the pathological case and for the dask-bypass case. The existing count-guard test still passes.

Fixes #1231.

Test plan

  • pytest xrspatial/tests/test_bump.py: all 18 tests pass locally (15 existing + 3 new)
  • bump(width=1_000_000, height=1_000_000) now raises MemoryError with a message naming the output raster size
  • bump(agg=dask_array_100k_x_100k, count=10) still works lazily without tripping the guard

_finish_bump allocated np.zeros((height, width)) with no memory
check. The existing bump-count guard only protected the locs/heights
arrays, so bump(width=1_000_000, height=1_000_000) passed the guard
(count capped at 10M ~ 160 MB) and then tried to allocate an 8 TB
float64 raster.

Extend the memory budget check to include the output raster bytes
(8 * w * h for float64) when the backend will materialize the full
array. Dask paths build the output lazily per chunk, so they are
excluded from the raster guard and continue to handle large
dimensions.
@github-actions github-actions Bot added the performance PR touches performance-sensitive code label Apr 23, 2026
The 20000x20000 default count test allocates a 3.2 GB raster, which
exceeds the new memory guard on 2 GB CI runners. The test only
verifies count-cap semantics, so bypass the guard via monkeypatch
instead of changing the guard or the test dimensions.
@brendancol
Copy link
Copy Markdown
Contributor Author

@copilot resolve the merge conflicts in this pull request

Co-authored-by: brendancol <433221+brendancol@users.noreply.github.com>
Copy link
Copy Markdown
Contributor

Copilot AI commented Apr 23, 2026

@copilot resolve the merge conflicts in this pull request

Resolved in 27b031f. The only conflict was in .claude/sweep-security-state.json — the branch had pathfinding and bump entries while master added a perlin entry. Both sets of entries are now present in the merged file.

@brendancol brendancol merged commit 5c0a0b5 into master Apr 23, 2026
11 checks passed
@brendancol brendancol deleted the issue-1231 branch April 25, 2026 12:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

performance PR touches performance-sensitive code

Projects

None yet

Development

Successfully merging this pull request may close these issues.

bump() output raster allocation lacks memory guard

2 participants