Bounds-check EventHandlerBase::is_ready() to fix out-of-bounds read (#2376)

[PavelGuzenfeld]

EventHandlerBase::is_ready() indexes wait_set.events[wait_set_event_index_], but that index is only assigned by add_to_wait_set(). If is_ready() runs before that the member is uninitialized; if it runs against a different wait set the index belongs to that other one. Either way the access reads out of bounds and can segfault (observed with ASan during a lifecycle configure).

This initializes wait_set_event_index_ to an always-out-of-range sentinel and makes is_ready() return false when the index is not within the wait set's events, instead of dereferencing it.

Adds two regression tests: one calling is_ready() on a handler that was never added to a wait set, and one where the index was assigned by a different wait set and equals size_of_events.

Builds on @aosmw's work in #2376; per @clalancette's review there, initializing the index alone is not sufficient (it could still point at another slot), so the bounds check in is_ready() is the actual guard.

---

Some of this change was produced with Claude Opus 4.8 (Anthropic).

[mergify]

Tick the box to add this pull request to the merge queue (same as @mergifyio queue).

• Queue this pull request

[sylvesterkaczmarek]

If add_to_wait_set() and is_ready() can genuinely race as described, the bounds check fixes the OOB symptom but wait_set_event_index_ is still read and written concurrently without synchronization. Should the index be atomic, or should the lifecycle guarantee be enforced another way?

[PavelGuzenfeld]

@sylvesterkaczmarek ,

Thanks for the review.

There's no actual race: is_ready() only runs from the executor's wait loop, on the same thread that called add_to_wait_set(), and the index only ever gets written by rcl_wait_set_add_event(). The real bug is simpler - the member gets read before anything assigns it. An atomic wouldn't help with that, or with the stale-index case.

p.s, Also added a test for the index == size_of_events boundary.