DijkstraMap pathfinding accepts out-of-bounds coords and aborts via TCOD assertion #311
Labels
No labels
Alpha Release Requirement
Bugfix
Demo Target
Documentation
Major Feature
Minor Feature
priority:tier1-active
priority:tier2-foundation
priority:tier3-future
priority:tier4-deferred
Refactoring & Cleanup
system:animation
system:documentation
system:grid
system:input
system:performance
system:procgen
system:python-binding
system:rendering
system:ui-hierarchy
Tiny Feature
workflow:blocked
workflow:needs-benchmark
workflow:needs-documentation
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
john/McRogueFace#311
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Found by:
fuzz_pathfinding_behaviortarget (W9)Summary
DijkstraMap::stepFromatsrc/UIGridPathfinding.cpp:63does not bounds-check itsx/yarguments before forwarding them toTCOD_dijkstra_path_set. Out-of-range coordinates trigger TCOD's internal assertion, which callsabort()directly from C code atlibtcod/path_c.c:600. This kills the interpreter with no recoverable Python exception.Reproduction
Crash input preserved at:
W9's own verification run also predicted this finding before the fuzz suite landed, so this is a known hazard we now have a concrete crasher for.
Root Cause
Suggested Fix
Add bounds checks in the C++ layer before calling into TCOD. Raise
ValueError/IndexErrorfrom the binding layer rather than aborting the process.The same pattern almost certainly applies to sibling methods on
DijkstraMap:distance(x, y)getPathFrom(x, y)Audit all DijkstraMap entry points that take coordinates and apply consistent bounds validation.
Scope
Part of ongoing memory-safety / input-validation hardening driven by the fuzz suite. Grouping all DijkstraMap coordinate validation into this one issue since the fix is a single consistent pattern across methods.