]> git.ipfire.org Git - thirdparty/asterisk.git/commit
manager.c: Invalid ref-counting when purging events
authorNathan Monfils <nathanmonfils@gmail.com>
Mon, 5 May 2025 08:47:43 +0000 (10:47 +0200)
committerNathan Monfils <nathanmonfils@gmail.com>
Tue, 13 May 2025 16:52:07 +0000 (16:52 +0000)
commit019d4ef17ce90d6655f67a8028d50b6067f1de66
tree6a75af4e9a7190bf7a57feba9b081e7b53d2ee20
parent0a249440015af0725849af5b2fd82b951e007ee4
manager.c: Invalid ref-counting when purging events

We have a use-case where we generate a *lot* of events on the AMI, and
then when doing `manager show eventq` we would see some events which
would linger for hours or days in there. Obviously something was leaking.
Testing allowed us to track down this logic bug in the ref-counting on
the event purge.

Reproducing the bug was not super trivial, we managed to do it in a
production-like load testing environment with multiple AMI consumers.

The race condition itself:

1. something allocates and links `session`
2. `purge_sessions` iterates over that `session` (takes ref)
3. `purge_session` correctly de-referencess that session
4. `purge_session` re-evaluates the while() loop, taking a reference
5. `purge_session` exits (`n_max > 0` is false)
6. whatever allocated the `session` deallocates it, but a reference is
   now lost since we exited the `while` loop before de-referencing.
7. since the destructor is never called, the session->last_ev->usecount
   is never decremented, leading to events lingering in the queue

The impact of this bug does not seem major. The events are small and do
not seem, from our testing, to be causing meaningful additional CPU
usage. Mainly we wanted to fix this issue because we are internally
adding prometheus metrics to the eventq and those leaked events were
causing the metrics to show garbage data.
main/manager.c